Standardize enabled, transmit, output and verbose configuration options

[ArturMoczulski]

There has been much confusion around enabled and verbose config options available across Rollbar SDKs. It is not clear to the users what each does versus what it is actually doing. We identified four different parameters that should control the behavior of the SDK in regards to it being enabled and how the logging is performed.

The new suggested configuration options authored by @rokob are:

I propose we have the following settings which are all independent of one another:

• enabled
  • If this is false then do absolutely nothing, try to be as close to the scenario where Rollbar did not exist at all in the code.
  • Default: true
• transmit
  • If this is false then we do everything except make the post request at the end of the pipeline.
  • Default: true
• output
  • If this is true then we output the payload to standard out or a configured logger right before transmitting.
  • Default: false
• verbose
  • If this is true then we output messages related to the processing of items that might be useful to someone trying to understand what Rollbar is doing.
  • Default: false
    • I would actually prefer this to be a level in increasing level of severity:
      • trace
      • debug
      • info
      • warn
      • error
      • none
    • The SDK would then have internal messages of different log levels and based on what you pick we would output only what you want to see, i.e. trace prints everything, error prints only the worst errors, and none prints nothing.

[ArturMoczulski]

When this is finished documentation for the SDK needs to be amended.

[ArturMoczulski]

I recommend using the standardized https://tools.ietf.org/html/rfc5424 protocol for the verbose levels. @rokob what do you think?