Simplify ForAttributeWithMetadataName

[CyrusNajmabadi]

Discussions with @sharwell have indicated that thsi code is not necessary. Specifically, consider the semantics of what 'Collect' does. It takes in the N values from an IncrementalValuesProvider (note Values not Value), and produces an IncrementalValueProvider containing an ImmutableArray<> comprised of those individual values.

Now, consider an IncrementalValuesProvider<T> P1 which produces an IncrementalValueProvider<ImmutableArray<T>> P2 by doing P1.Collect(). If P1 produces the same values as its prior run, then that will be detected by the engine, which will cut off further processing, keeping P2 with the same array as hte prior run.

If, however, P1 does change in any way (according to its comparer) then we necessarily must get a new array in P2 containing those values. There is no need or value here for P2 to have any sort of array-comparer as we actually want array-identity to determine if P2 is creating new outputs or not.

--

Consider an example. Say that P1 produced "1", "2", "3", and thus P2 is ["1", "2", "3"]. If on rerun, P1 produces the same values (by equality, not necessarily identity), then we will get the same array, which will already behave properly with reference equality semantics. If we change to "1", "2", "4" though, and we produce ["1", "2", "4"], it does no good to do sequence equality for these arrays. They will be different (as otherwise we wouldn't generate the ImmutableArray in the first place). As such, doing a reference-equality check is actually preferred as it's O(1) instead of O(n).

[AlekseyTs]

@chsienki Please review