[core.logging] Provide mechanism for configuring default appenders for specific loggers

[lukeelmers]

In #87939 we merged support for request/response logging to the KP. One of the issues that surfaced was that logs suddenly became very cluttered as the LogMeta that's attached to the response logs can be quite large.

The temporary workaround we discussed was to simply remove meta from the default pattern layout, so that folks would need to "opt-in" to view the meta when using pattern layout by defining a custom appender.

However, a more ideal approach might be to have a mechanism where you could specify context-specific appender defaults to apply when no other configuration is provided, as discussed in #90457. This might be a little similar to the Elasticsearch default logging config file.

A solution like this could solve a variety of problems, such as:

• specific loggers that output too much data (e.g. for http response logs, default to a custom appender that has no meta)
• specific loggers that should automatically have sensitive data filtered unless a user disables it (e.g. a default RewriteAppender that filters cookies/auth headers as discussed in [core.logging] Add RewriteAppender for filtering LogMeta. #91492 (comment))
• loggers that benefit from a more specific pattern layout which differs from the default
• migration scenarios where you might want to preserve a different BWC format for a particular logger (this one is hypothetical, we admittedly don't have a concrete need for this today)

Once we remove the injected "default" legacy appender in 8.0, it might be a good time to consider this as an enhancement.

We'd need to discuss how to implement this, but in general I'd imagine a dedicated file where the defaults are specified, and then get merged into the logging config's configSchema.defaultValue & applied whenever the logging system is upgraded.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

I don't think we need this anymore, so I'm going to close it.