Fix dial type interface before "public" release

[ClarkMcGrew]

In the next release, the internal dial interface will more flexible and efficient. The YAML dial interface needs to be upgraded to support the new functionality in a way that describes the functionality of a dial, not how it is implemented.

Background: The existing (1.6.1 and before) interface supported a limited number of dial types (e.g. normalization, spline, graph) while the new dial interface can support multiple types of splines, and even multi-dimensional dials. For debugging, the user interface has been tied very closely to the dial implementation, but this will become unmaintainable as the number of implemented dial types increases.

Proposal: Design a YAML dial interface that describes how a dial should behave, but which is not closely tied to the implementation. (Comments will include proposal options)

[ClarkMcGrew]

Proposal for dial interface extension: Hierarchical Interface

The current dial interface supports the dialType "field". The 1.6.1 options being used are "Normalization", "Spline", and "Graph". This proposal is to keep the essential structure and use dialSubtype to make the dial behavior more specific. This fits well with using a "Factory" implementation pattern.

Proposal for the current "master" interface:

• Normalization/Norm -- Do not use dialSubtype.
• Graph -- Provides linear interpolation. Dial subtype can provide implementation hints
  • Light -- Use a light implementation
  • ROOT -- Use the ROOT TGraph implementation
• Spline -- Provide a 1 D spline interpolation
  • not-a-knot -- Use the default ROOT spline behavior
  • natural -- Use a natural spline
  • catmull-rom -- Use a catmull-rom spline
  • monotonic -- Apply a monotonic constraint to the spline. This could (should?) be a modifier to the other sub-types (e.g. not-a-knot:monotonic, catmull-rom:monotonic, etc).
  • cached -- Use a local cache for the spline. This should be a modifier to the other sub-types (e.g. not-a-knot:cached, not-a-knot:monotonic:cached)

[ClarkMcGrew]

Proposal for dial interface extension: Flat interface

As before, but keep interface without using dialSubtype. The new spline interface could be

• Normalization/Norm
• Graph
• LightGraph
• Spline -- The default root behavior
• NaturalSpline
• CatmullRomSpline
• MonotonicCatmullRom Spline
• CachedSpline
• CachedNaturalSpline
• etc

My comment is that this type of interface could have a "complexity explosion" and become very difficult to maintain. Particularly if we add extensions like multi-dimensional dials.

[ClarkMcGrew]

Closed by #273. The final interface is slightly different than the first proposal above, but qualitatively the same. The intermediate interface accepts deprecated dialsType values, but I think we should be removed the deprecated types before the freeze so that we don't need to support them going forward.