FLUID-5249 work kicked up the observation that our options merging implementation is faulty when grades are merged containing multiple representations of "deep trees" - because our support for mergePolicies cannot see into the "components" area and we do not store their contents in an appropriate way when merging.

For example, in the case where we have

fluid.defaults("gradeA", {
    components: {
        sub: {
            gradeNames: "gradeC"
         }
    }

and

fluid.defaults("gradeB", {
    gradeNames: "gradeA",
    components: {
        sub: {
            gradeNames: "gradeD"
         }
    }
}

we then end up with the subcomponent grade of "gradeC" eliminated completely from gradeB's tree rather than merging additively as one would expect. This is because we don't have any appropriate representation for the "superposition of deep trees" that would allow the normal grade merging algorithm for "sub" to apply the proper merge policy to its grades when it comes to resolve. This is a pretty serious fault that will end up upsetting someone before long. The workaround is to ensure that we only attempt such "deep" definitions along a single path in the grade hierarchy, which in the end is going to end up excluding some valid designs.