Added Calculated Symbols and improved ValueProvider

[KathleenDollard]

Creating CalculatedSymbol exposed flaws in the ValueProvider logic, so I went ahead and added the check for reentrancy. These can be severed if needed.

I also started an OpenQuestions document so we can scribble notes.

Calculated values

The benefits of calculated values:

• Replacing custom parsers with a formal way to get an array and process it after parsing
  • Formalizes the pattern and allows us to solve the known and necessary case of dotnet nuget why
  • When an array is split at this point, we can apply validation, etc.
• Code reuse if the same concept is used in multiple ways along with the ability to name it
  • For example: "EndOfProbabtion" which is 90 days after hire date may be the first date for certain actions
• Performance if an expensive value is used more than once
  • For example: the current project file may be used both in a must exist and a default value context
• Compound values
  • For example, cases like Point where a value may be created from several CliValueSymbols just works
  • For example, this could be an easy way to handle things like the dotnet nuget why problem where backwards compatibility requires the use of a first argument being optional
• Subsystems that need to define values for the Pipeline instance would have a simple place to store them with all the support described here
  • Chet has mentioned this for the number of items returned in large or infinite completions
• Structuring these scenarios would allow documentation of calculated values and how they are calculated

This is a sufficiently small amount of work, that I would recommend it even if only because it solves the nuget why problem so elegantly.

Other notes on the PR

There are also test for dotnet nuget why which in ValueProviderTests. In this case one array input is split into two values.

I think CalculatedValues, along with dependent value sources for validation, will accommodate the majority of current use of custom parsers (which we do not plan to support).

We should discuss the API for CalculatedValue with multiple input symbols. This is needed for the compositing problem, which is demonstrated by the Point2D test in ValueProviderTests. This is particularly ugly because RelativeToSymbolValueSource nad RelativeToSymbolsValueSource have a different order of parameters due to params and default values. However, there is first a deeper discussion on whether it should be multiple symbols, or an aggregate that can handle any ValueSource. For example, it is an easy hop from where we are in this PR to a value that relies on a combination of calculations with no dependency (such as offsets from today), values that are calculated relative to another symbol, and ones that are relative to an environment variable. It's all just how we allow people to use ValueSource

[KathleenDollard]

I made some naming changes that were really bothering me, and clarified how collection value sources work, which will hopefully help differentiate the collection value source and FallbackValueSource. I look forward to further discussions of the API.

[KathleenDollard]

Per discussions with Mikayla, we want to explore using custom type providers in the core layer to solve the problems calculated values is solving in the subsystem layer in this PR.

For clarity, I am closing this PR and replacing it with a PR that has the other work that was included in this PR.