Allow configuring observation registry directly

[cfredri4]

This changes allows configuring the observation registry directly, instead of it being fetched from the application context. This is to allow observability when KafkaTemplate/KafkaMessageListenerContainer are used without an application context.

[sobychacko]

@ cfredri4 I think this needs more discussion. These changes modify the behavior of setting the default NOOP observation registry for both KafkaTemplate and the listener container. Why do you need to provide the ObservationRegistry as a non-bean, and why is the application context absent? Since there are some design changes in the PR, we will discuss this internally soon, but you can just give some more context around the changes. Thanks.

[cfredri4]

@cfredri4 I think this needs more discussion. These changes modify the behavior of setting the default NOOP observation registry for both KafkaTemplate and the listener container.

This was for simplicity's sake as the registry is nullable and null and NOOP are treated the same. But I can change back to NOOP if desired.

Why do you need to provide the ObservationRegistry as a non-bean, and why is the application context absent? Since there are some design changes in the PR, we will discuss this internally soon, but you can just give some more context around the changes. Thanks.

I have two situations where this change would be beneficial:

1. We sometimes use Spring Kafka in applications which are not Spring applications, i.e. they do not have a Spring application context. Here we need to create a mock ApplicationContext which implements getBeanProvider to return the registry; this is messy and fragile as it's dependent on internal logic in how KafkaTemplate/KafkaMessageListenerContainer works.

2. We sometimes have the need to use a different observation registry for Spring Kafka than what is in the application context. Here we need to do similar to # 1 above but then also make sure that this is done after Spring has already initialized KafkaTemplate/KafkaMessageListenerContainer as this time they are Spring beans.

Both of these situations would be trivial had it been possible to configure the observation registry directly.
Exactly the same thing can already be done for the KafkaAdmin, so to me it makes sense to allow it also for the observation registry.