Add 'logging' as new metric export type

[vpelikh]

It's useful to see metrics in the console during development, without having to set up an LGTM container or write additional code.

[jonatan-ivanov]

It might make sense to add auto-configuration for LoggingMeterRegistry but I feel your original problem statement:

It's useful to see metrics in the console during development, without having to set up an LGTM container or write additional code.

might be easier to resolve using the /actuator/metrics or the /actuator/prometheus endpoints. LoggingMeterRegistry is not on-demand, it's a "step" registry, you need to wait for the logs to be emitted (once per minute by default). Also, Boot registers quite a few metrics, finding them in the logs might not be that easy as using the actuator endpoints above.

[danish-ali]

You verify back-off when a Clock is absent, but not when LoggingMeterRegistry itself is missing.
Could we add an ApplicationContextRunner test with a FilteredClassLoader(LoggingMeterRegistry.class) to assert that neither LoggingMeterRegistry nor LoggingRegistryConfig is created? That would complement the @ConditionalOnClass(LoggingMeterRegistry.class) path.

Additionally, minor naming nit in LoggingMetricsExportPropertiesConfigAdapterTests: some methods refer to “AggregationTemporality” but assert logInactive(). Consider renaming to reflect logInactive to avoid confusion.