Support for externally created Java SE containers

The idea behind CDI 2's Java SE containers was that a "normal" Java SE `main` method would configure and create an instance of `SeContainer`, while *all* libraries and frameworks (*including* Jersey) used by that Java SE application would provide CDI Extensions to be able to re-configure that *existing* container.

The existing Java SE support documented by the [CDI 2 SE Hello World and Counter Example](https://github.com/eclipse-ee4j/jersey/blob/master/examples/helloworld-cdi2-se) relies on Jersey *producing* the container, hence [the actual Java SE application](https://github.com/eclipse-ee4j/jersey/blob/master/examples/helloworld-cdi2-se/src/main/java/org/glassfish/jersey/examples/helloworld/cdi2se/App.java) is unable to configure and create the SE container upfront - or in other words, if it would do it as intended by the CDI 2 specification and shown in lots of tutorials, there would be *two distinct* containers in the end.

To "correctly" support CDI 2 Java SE Containers *in the way intended by the CDI specification* (i. e. Jersey *re-configures pre-existing* containers instead of *creating* a container), Jersey's CDI 2 module must get modified to *not* create a container but to rely on the actual Java SE application's creation of one. Jersey must simply be a CDI Extension which *modifies* that container (i. e. Jersey reacts upon CDI events and uses BeanManager to add more beans). In turn, the example application must explicitly create a container instead of letting Jersey do that.