Some naming issues for UIOptions

[Antranig Basman]

I think that yzen's branch for FLUID-4686 reforming UIOptions' Store grade at
https://github.com/fluid-project/infusion/pull/323/files is nearly ready to go, but it has exposed some 
global naming issues with our reworking of the component.

An overall aim of this refactoring has been to produce a set of base grades which are "empty" so from the 
point of view of our integrators (3rd parties) they have the ability to start from an empty canvas as 
regards building new configurations of UIOptions.

It has been our practice to give the name "default" to those particular "filled" grades which represent what 
we have come to call the "out of the box" configuration of UIOptions, representing its default panels and 
settings.

For example, for the component still named "fluid.uiEnhancer", this grade itself now contains no 
settings-specific material, and these definitions have been moved to a grade named 
"fluid.uiEnhancer.defaultActions".

Similarly, for the component still named "fluid.uiOptions", this grade is empty, and all definitions for the 
built-in panels have been moved into "fluid.uiOptions.defaultSettingsPanels".

This kind of convention seemed to work reasonably well until we got to the grade already named 
"fluid.uiOptions.defaultModel" created in the FLUID-4686 branch. For this grade, the meaning of the word 
"default" refers to "the default state of the UIOptions model for a particular configuration, before the 
user has modified any settings", rather than the meaning of "default" in the cases I cited earlier, where it 
means "the particular configuration of UIOptions that comes 'out of the box'".

By analogy with the above grades, we need a default "empty" version of the "defaultModel" grade which would 
seem to involve a confusing further use of the word "default". As the branch stands, the "empty" grade is 
named "fluid.uiOptions.defaultModel" and the "filled" grade is named 
"fluid.uiOptions.defaultModel.outOfTheBox" which is descriptive but breaks the pattern of the previous examples.

I'd like to ask the community for comments and suggestions on this issue, as well as the general issue of 
the level of API compatibility we are committed to for this release. My understanding is that since 
UIOptions has so far only reached "preview" release status, we are not overly concerned with breaking API 
changes where they are well-motivated. One particular issue which comes to mind is the renaming of the 
UIOptions Store method from "fetch" to "get" and "save" to "set" as more conformant with the DataSource API 
we have established elsewhere (for example, in the GPII and CSpace).

Cheers,
Antranig