Revisit API for BeanContainer

[manovotn]

Currently, the BeanContainer methods for bean resolution are pretty confusing for users.
The way it works is that a bean resolution is attempted and if there is no bean found, a default fallback is executed. However, this fallback is pretty simplistic and tries to instantiate an object via no-arg constructor which may or may not exist.

The current javadoc also seems to be fumbled now that I read it again (which is something I might have butchered back then) - the deprecated version should be the one that doesn't throw ambig. dep. exception which isn't quite clear now.

We could do some (or more) of the following:

• Deprecate all bean resolving methods in this API and eventually delete them
  • The beanInstance and the beanInstanceFactory methods
• Introduce a method providing access to Arc container
  • Basically just returning Arc.container(); user can do the rest from there
• Retain beanInstance but change it's behavior so that it either returns the bean or null leaving user to handle the fallback in whichever way they want to
  • We could still deprecate/drop the beanInstanceFactory method in this case

Personally, I'd deprecate current methods and introduced two new ones:

• One a convenient access method to ArcContainer
• The other similar to beanInstance but well defined in that it performs a lookup, resolves ambiguity but in case no bean is found allows user to handle null whichever way they choose to

While at it, we should also look into internal usage of BeanContainerBuildItem - this is still useful to detect a 'container-ready' state in STATIC_INIT but has no real value in RUNTIME_INIT as the container is always active at that point in time.
For instance AmazonLambdaProcessor depends on this item for no real reason.