Provide facility for dynamically resolved component gradeNames

To bring the ProgressiveEnhancer up to modern framework standards, as well as implement "demands block horizons" (FLUID-4917), as well as for various other purposes (e.g. "nonce request grades" within GPII/Kettle) we require support for components whose grade hierarchy is dynamic.

Initially we plan support for schemes like the following,

fluid.defaults("fluid.progressiveChecker", {
gradeNames: ["fluid.typeFount", "fluid.littleComponent", "autoInit", "

.check" is an invoker resolved on the current component. The initial requirement is for the gradeName set to be updated so that we can use a FLUID-4914-based system for operating the ProgressiveEnhancer, rather than it producing just the single typeTag that it previously used to via a now-illegal indirect return system. As well as allowing the progressiveChecker to be given a standard automatic component workflow, this will also allow it to "return" multiple typeTags (as a result of being able to match all gradeNames throughout its hierarchy, including those returned from

.check) which as well as being useful in itself, will allow us to implement the "demands block horizon" system which will prevent more than one instance of a progressiveChecker for the same component to be taken into account during resolution.

Future requirements will expect the entire defaults block for the new grade hierarchy to be switched in. This will be perfectly possible, so long as the invoker in question does not provoke the ginger process to examine any "unsuitable" parts of the component, for example any of its subcomponents.