Fix CollectionModelBinder BindSimpleCollection null value handling

[campersau]

Fix CollectionModelBinder BindSimpleCollection null value handling

null is now ignored instead of receiving the previous value.
Because StringValues of null equals ValueProviderResult.None and the CompositeValueProvider contained the ElementalValueProvider from the previous iteration, it got used instead.

There was also an interesting case when null is the first value, because then the original IValueProvider might be called again, which returns the original array (or something else if it is computed) and because the array can not be bound to an element value it received actually null.

I don't think the CompositeValueProvider is needed at all, also the bindingContext.ValueProvider should be set inside of EnterNestedScope so the original bindingContext.ValueProvider is properly restored afterwards.

Input	Before	After
[42,100,null,200]	[42,100,100,200]	[42,100,200]
[null,42,100,200]	[null,42,100,200]	[42,100,200]

Fixes #40929

⚠Dangerous hack to get `null` values ⚠

Since ValueProviderResult.None is currently not readonly (I guess that's a bug?) you can set it to something else and then you would get null back instead of it being ignored:

ValueProviderResult.None = new ValueProviderResult(new[] { "please don't ignore null!" });

[ghost]

Thanks for your PR, @campersau. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dougbu]

I'm fine w/ this version but defer to @brunolins16 for final approval.

One slight reservation: It feels odd to favour functional tests over unit tests here. Were we previously missing coverage of custom IValueProviderFactory / IValueProvider implementations❔

[brunolins16]

The change looks good. Thanks for that. I have a small ask for an additional test and we will be good to go.

[brunolins16]

@campersau Thanks for your contribution.