Revisit Reactive context hierarchy

The context hierarchy for reactive support contains a number of classes that do not seem very useful:

• ConfigurableReactiveWebApplicationContext seems to be a marker interface
• StandardReactiveWebEnvironment is just a StandardEnvironment that implements the empty ConfigurableReactiveWebEnvironment marker interface

There are two distincts reasons for this hierarchy

ConfigurableReactiveWebApplicationContext seems to be only used by ReactiveWebApplicationContextRunner. The bottom line is that the supplier must provide a ConfigurableReactiveWebApplicationContext but what the infrastructure really requires behind the scene is a ConfigurableApplicationContext that can be identified by the conditions as being reactive. Such type does not give you that guarantee as you may have a context that implements ConfigurableReactiveWebApplicationContext but returns an Environment that is not a ConfigurableReactiveWebEnvironment. Perhaps we could remove this in benefit of a check of the environment as that's what our condition is mostly using.

As for the environment itself, a SpringBootEnvironment that is a StandardEnvironment and has a WebApplicationType accessor would be enough for most use cases except the servlet one. Rather than creating a complete hierarchy for that, maybe we should simply create such dedicated environment and check for its presence in the conditions?

Start by tracing ConfigurableReactiveWebApplicationContext, StandardReactiveWebEnvironment, ConfigurableReactiveWebEnvironment, and ReactiveWebApplicationContextRunner, then inspect how the conditions identify reactive contexts. Done means reaching agreement on a simpler hierarchy or environment design and updating the affected infrastructure and condition checks consistently.