Expand annotation accessor pattern

[KathleenDollard]

Annotation accessors were initially envisioned as a single widely used struct. But since it serves as the pipeline between the data provider and the CLI author, it would be desirable to expand its use. Since it is, and should probably remain, a struct this means we are using the annotation pattern in other scenarios. These variations are in the signature and overloads of Set and TryGet.

While this would add complexity to the subsystems, it would allow annotation accessor usage to be tailored for CLI author convenience.

The proposal is to embrace annotation accessors as a pattern, rather than a single class. Examples are the ValueAnnotationAccessor and ValueFuncAnnotationAccessor in #2413.

Some examples:

Parameter type checking:

• DefaultValue needs to be held in a collection of object?, but if we have the specific symbol, we can ensure Set requires a parameter of that type and TryGet supplies the correct value type
• DefaultValueCalculation is similar to the above, except that Func<TSymbolType> is used in Set and TryGet

Multiple overloads

• All of the annotations on value should occur only on CliOption and CliArgument. This can be done with overloads
• If the type of the symbol is held in a collection, it is held as CliSymbol (non-generic). Thus, annotations like DefaultValue need a non-generic version

Additional methods

• It is possible that some annotations will benefit from a Get method to simplify callsite usage

Custom behavior

• If we consider annotation accessors a pattern, instead of a single class, we open the possibility of convenience overloads for the CLI author, such as having multiple parameters that are used to create the item to store
• We could validate arguments prior to storage or modify such as providing a ceiling or floor