nested aggregate hierarchies

[Jim Marino <jm...@myroma.net>]

I committed another round of changes to allow registration of  
arbitrarily deep aggregate hierarchies. Prior to this, we had to do  
the following:

1. Register a module component with an "empty" module
2. Register the module component's module
3. Locate the context associated with the module component
4. Register child aggregates with the context

...and continue this for each level in the hierarchy

Now, we can just register the top-most aggregate and the builders  
will lazily recurse down, i.e. they will perform the necessary  
registrations as children are located. This means that we no longer  
have to register the module component and then the module, as this is  
all done in one step. Of course, we can still add children "manually"  
in their parent context. For an example,  
see  .o.a.t.core.system.context.AggregateNestingTestCase.java.

As part of these changes, I've also done the following:

- Made autowiring resolve semi-lazily when an instance is created  
(completely lazy would be when the reference on the instance was  
accessed).
- Fixed the "wrong" parent context problem
- Decoupled building from the parent context and updated the builder  
API to reflect this. Builders no longer need to access the parent  
context, allowing the build phase to be done without instantiation of  
runtime artifacts.  This is necessary for the nested aggregates to  
work properly

I was also able to make ConfigurationContext extend the  
ContextFactoryBuilder and  WireBuilder interfaces. I think having one  
interface for joining these two makes things a bit easier when  
writing aggregate context implementations but we can discuss. If we  
do away with ConfigurationContext, we can have the aggregate  
implementations implement the builder interfaces directly.

Jeremy, you should be able to go ahead with your changes to remove  
registration of builders on the runtime context. Hopefully it will  
work and there are not too many bugs :-)

Jim