[hibernate-dev] ManagedBeanRegistry - dependency injection support

https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly about back porting the work I did on 6.0 for the ManagedBeanRegistry abstraction over dependency injection containers. We will ship support for CDI as well as non-managed beans (things we directly instantiate). Of course we'd ideally make it easy to plug in other DI containers such as Spring. So I wanted to discuss the configuration of this support. The first thing to consider is whether we want to support using multiple DI containers simultaneously. E.g. is it conceivable that an application might want to use both CDI and Spring simultaneously? I started building in support for that via a CompositeManagedBeanRegistry implementation, but stepping back I want to gauge whether that is "reasonable" before continuing down that path Assuming that we do want to support such "compositions" the next question is how we see this being configured. Clearly any time a CDI BeanManager is present during bootstrap we want to enable CDI ManagedBeanRegistry support. How would users indicate additional ManagedBeanRegistry impls be added to the CompositeManagedBeanRegistry? I have opinions about this, but I'd like to hear other's thoughts... Note that ManagedBeanRegistry is a service and is initiated via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it would be possible to completely redefine ManagedBeanRegistry support simply by replacing that initiator. A minor point... notice that the package name here is `org.hibernate.resource.cdi`, even though one of the goals here is to support non-CDI ManagedBeanRegistry impls. Do we want to use a different package name? Maybe `org.hibernate.resource.beans`? ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - imo "cdi" conveys the proper intent. But if others feel strongly it should be something else, I am open to hearing what and why.