Implement logging to the Drupal Logger with submitting custom fields as the context metadata

@smustgrave, thank you for the implementation!
My main concern there is that the logging is named as "Drupal database logging", but actually, the Logger module is not about the database, it just extends the standard Drupal logs to allow storing any free-form metadata and other custom fields.

Also, this approach should work with the Monolog logger too.

So, let's name the feature as something like "Drupal extended logs", with description like this:

Enables logging events to the standard Drupal logger with passing the event data to the context. This feature requires extending the default Drupal Logger by one of these modules: Logger, Monolog, Logger DB.

What do you think about this?

And, by the way, I'm working now on decoupling the Logger DB module from the Logger, so it will work well independently, here is an issue with this feature: #3555898: Add support for Monolog and Drupal Core logger without the Logger module

Also, if we implement this feature, we can simply get rid of (or, at start, just mark them as legacy) all other logging types (cli, syslog, stdout), because these log targets can be handled well by the Logger or Monolog modules, and the scope of the events_log_track module will be just prepare a log entry with all required data.

And, together with this, get rid of other log handling code, at least the cron job, handling the enable_log_deletion feature, timespan_limit, batch_size, etc. Because the log clean-up and rotation should be the responsibility of the logger side, not this module.

Yes, let's not introduce the required dependency on the Logger module, just optional one.

And, to add "integration" with Logger (and with Monolog too), all you have to do - is just to add all the custom data to the "context" array of the Drupal default logger. So, instead of introducing a new logger, if you already have integration with the watchdog, maybe it's better to just add there an option "Add custom fields data to the log entries", with the description like this:

Enables passing the event data to the context of the log entry. This feature requires extending the default Drupal Logger by one of these modules: Logger, Monolog, Logger DB.

I'm not about massive changes, but the opposite - trying to suggest minimizing the changes and the amount of the custom code. In the issue #3534876: Rework AI logging to use the default Drupal Logger with passing metadata in context, you can see how the integration with the Logger module was done for the "AI" module.

And here #3535260: Provide AI usage reports in Drupal admin panel you can see how the custom log report page can be implemented, displaying the specific log entry fields as separate columns, with filitering by them.

Also, take a look on the Request Logger module integration https://www.drupal.org/project/request_logger as a reference.

Sorry for the delay, reviewed now and even tested locally - it works well! But seems we have to make the settings form clearer, left comments in the MR about this.

Also, it would be good to track the installation of the syslog and stdout modules and show them in the settings form, to inform the user that the module starts logging to those targets too.

And, maybe add a note that instead of separate modules syslog and log_stdout, now users can just use the Logger module for all targets - db, syslog, stdout, and everything else.

Also, maybe plan a separate issue to create a submodule with the Logger DB dependency (to not introduce the dependency in the main module) that provides a Views page, which will represent logs stored by the Logger DB as a table like the current table on the page /admin/reports/events-track, to be able to completely get rid of the custom storage?