SteveSandersonMS Cascading parameters (#1545)
* Add Provider component

* Implement discovery and matching rules for tree parameters

* Remove artificial component hierarchy unit tests now they are redundant

* Refactor: Have RenderTreeFrame point to the ComponentState instead of IComponent

... so we can more quickly find associated tree param state without having to do lookups based on the componentId.

Also rename AssignComponentId to AttachAndInitComponent to be more descriptive.

* Refactor: Add shared code path for updating parameters so there's only one place to attach tree parameters

Now framework code should no longer call IComponent.SetParameters directly, except if it knows it's definitely dealing with a root component.

* Refactor: Simplify Parameter by making it hold the name/value directly

This will be necessary for tree parameters, which don't correspond to any RenderTreeFrame

* Refactor: Wrap ParameterEnumerator logic in extra level of iterator so we can also add one for iterating tree params

* Extend ParameterEnumerator to list tree parameters too

* Include tree parameters in SetParameters calls

* Refactor: Move parameter change detection logic into separate utility class

... so we include dotnet/jsinterop#3

* Refactor: Move tree parameter tests from RendererTest.cs their own file

* Have Provider re-render consumers when value changes. Unit tests in next
commit.

* Components that accept tree parameters need to snapshot their direct params for later replay

* Empty commit to reawaken CI

* CR: Make name matching case-insensitive

* Refactor: Rename Provider/TreeParameter to
CascadingValue/CascadingParameter

* Add dedicated [CascadingParameter] attribute. Remove FromTree flag.

* CR: CascadingParameterState cleanups

* CR: Extra unit test

* CR: arguments/parameters

* CR: Enumerator improvements

* Fix test
Latest commit a0fc692 Oct 15, 2018