Corrected grade merging algorithm FLUID-5085, adjustment to "fluid.uiOptions.transformDefaultPanelsOptions"

[Antranig Basman]

I have rewritten the core grade merging algorithm in the framework as per
http://issues.fluidproject.org/browse/FLUID-5085 and
http://issues.fluidproject.org/browse/FLUID-5108 - this thankfully went off with fewer problems than feared 
for so fundamental a change, but not unexpectedly did cause a small hiccup in the UIOptions hierarchy - 
recent versions of this include a mixin grade "fluid.uiOptions.transformDefaultPanelsOptions" which I think 
in itself probably needs a bit of reworking, but in the meantime to work with the new system it required a 
change in its grades list from ["fluid.uiOptions.inline", "autoInit"] to ["fluid.viewComponent", "autoInit"]

This is because all the test cases where it is used supply it as a direct option grade which per the new 
rules take priority over any builtin grades - from FatPanelUIOptionsTests.js we have

     fluid.defaults("fluid.tests.fatPanelIntegration", {
...
         components: {
             fatPanel: {
                 type: "fluid.uiOptions.fatPanel",
...
                 options: {
                     gradeNames: ["fluid.uiOptions.transformDefaultPanelsOptions"],

where the mixin has grade "fluid.uiOptions.inline" this causes a conflict with the material in 
"fluid.uiOptions.fatPanel" itself which has

     fluid.defaults("fluid.uiOptions.fatPanel", {
         gradeNames: ["fluid.uiOptions.inline", "autoInit"],
...
             uiOptionsLoader: {
                 type: "fluid.uiOptions.fatPanelLoader"
             }

The key issue here is the refined type of "uiOptionsLoader" which is required to make all the iframe 
injection work correctly. If "fluid.uiOptions.transformDefaultPanelsOptions" is given the grade 
"fluid.uiOptions.inline", the effect as used in the test case is to re-override the grade material defining 
"uiOptionsLoader" back to the defaults in "fluid.uiOptions.inline" which has this as a plain 
"fluid.uiOptions.loader".

There are a few ways to avoid this issue but revising the mixin grade seemed the most straightforward - but 
this highlights the care needed to avoid trumping builtin material with high priority dynamic grade 
information in the new system. At least the new rules are clear and consistent even if they have now 
diverged even further from those operated by type systems from the "object-oriented" mentality.

I left an implementation comment on the mixin grade itself since at the very least it needs a name change, 
and really needs some rewriting since right now there is the odd situation that its use only appears in test 
case drivers - it should really be folded into the rest of the "starter" grade system.

https://github.com/fluid-project/infusion/pull/390/files

Cheers,
A