Building on the FLUID-4330 ginger world work, and preparatory to the "wave of promises" asynchronous ginger world, we can offer a significant improvement in regularity to the users of IoC by eagerly instantiating "component shells" and any type founts preferentially to evaluating any other contents of their options in the ginger process. This will allow reliable type-based access to components without requiring a dependence on instantiation order or reliance on hard-coded paths. For example, in this situation in the Uploader, the base component

fluid.uploader.multiFileUploader
 |
 +--- fluid.uploader.fileQueue
 |
 +--- fluid.uploader.html5Strategy
       |
       +--- queue

We would like to write the injection of the fileQueue as

            queue: "fluid.uploader.fileQueue"

but instead must write it as:

            queue: "{uploader}.queue"

This is because despite being a more deeply nested subcomponent of the base, we can't guarantee that the framework has not chosen an instantiation order which recurses more deeply on html5Strategy and has not yet seen the typename of the queue as "fluid.uploader.fileQueue" as the member at path "queue". The former form is preferable since it imposes less tight binding on the exact location of the fileQueue.

In the "wave of explosions" a wave of instantiations will spread eagerly from the root, in breadth-first order, with the usual priority given to type founts, and ensure that in virtually all cases by the time the body of any component options are expanding, the "type skeleton" of the entire component tree will be available (barring any components whose types depend on some portion of their options body material)