Enable structured JSON logging for SLF4J `2.0.0`+

[vcolin7]

### Tasks
- [ ] Add code to check whether SLF4J `2.0.0`+ is being used to use its the new APIs
- [ ] Determine how we want to JSON structured logging to look like
- [ ] Adapt code to newly determined standard

[lmolkova]

Determine how we want to JSON structured logging to look like

There are two options:

1. Don't change anything for SLF4J 2.0. As a result, SLF4J 2.0 providers would get string message (which happens to be structured json) and won't see individual key-value-pairs

   • Pros: when writing logs to file/console, the default formatter would print log message as a whole.
   • Cons: when writing logs to structured destinations, the message will remain a string and will need additional parsing when querying data

2. Leverage the structure and use SLF4J 2.0 addKeyValue methods to provide the context to the SDLF4J

   • Pros: when writing logs to structured destinations, users will get better experience
   • Cons: when writing to file/console, the default formatters will NOT include any context. And would just print the message

The middle ground:
E.g. we want to record the following log: connectionId=foo, error.type=canceled, message="Connection attempt failed"

With SLF4J 1.7 we record message as {"connectionId":"foo", "error.type":"canceled", "message":"Connection attempt failed"}
With SLF4J 2.0 we record structured things and a formatted message like

slf4JLogger.atInfo()
  .addKeyValue("connectionId", "foo")
  .addKeyValue("error.type", "canceled")
  .addKeyValue("message", "Connection attempt failed")
  .log("{\"connectionId\":\"foo\", \"error.type\":\"canceled\", \"message\":\"Connection attempt failed\"}")

This would be a default behavior resulting in:

• giving all the structure to providers that support it
• still having all the context and message in the formatted json string in the message for default formatters.

It'd result in duplication and we can consider letting users to configure it.

---

My proposal is to do 1.5 eventually, but stick with option 1 for now until we have any feedback/scenario for option 1.5.

By doing option 1, we effectively do

slf4JLogger.atInfo()
  .log("{\"connectionId\":\"foo\", \"error.type\":\"canceled\", \"message\":\"Connection attempt failed\"}")

and

  .addKeyValue("connectionId", "foo")
  .addKeyValue("error.type", "canceled")
  .addKeyValue("message", "Connection attempt failed")

is purely incremental change.

[lmolkova]

The problem with this approach is that slf4j 2 requires user to configure kv list in the output. The assumption is that many users don't and by leveraging slf4j structured logging we'd drop all significant information for most of the users.