Fixed bogus lookup logic within list-land .TransformAsync(),…

[JakenVeina]

… for processing changes with unspecified indexes, which resulted in Remove and RemoveRange changes with unspecified indexes to be ignored completely.

[dwcullop]

Fix looks right to me. Matching on EqualityComparer<TSource>.Default lines up with how TransformedItemContainer already defines equality.

The synchronous Transform has the same bug, though, so it'd be good to fix both here:

• List/Internal/Transformer.cs:146 and :165 match indexless removes with ReferenceEquals(t.Source, change.Current). For value types that's always false because both sides get boxed, so an indexless Remove/RemoveRange of ints is silently dropped, which is exactly #1169.
• The RemoveRange branch there (Where(t => item.Range.Any(...)) into RemoveMany) also removes every duplicate of an item, not one per entry in the range.
• TransformFixture.RemoveWithoutIndex only uses Person, so nothing catches it. Mirroring your two new int tests against Transform would.

As it stands sync and async also disagree on what "the same item" means (reference identity vs Equals), which seems worth closing while we're here.

Small nit on the lookup itself: the Select((pair, index) => (sourceItem, (int?)index)).FirstOrDefault(...).index trick takes a second read, allocates per remove, and is duplicated. A plain index loop in one helper that both Transformer and TransformAsync call would be simpler and keeps the two operators from drifting again.

[JakenVeina]

Fair point about putting equivalent fixes on .Transform().

I'm not too fussed about the optimalness of the index lookup, when that's SUCH a "this really shouldn't be a thing" scenario, but looking at it, I realized there were actually several OTHER inconsistencies (for other change types) in how index lookups are being done, across both operators. So yeah, I just added a helper method and refactored it into both operators, everywhere an index lookup is needed.

There's still inconsistencies in how the operators handle an index lookup that FAILS (some change types will throw, some will just silently ignore the change) but I opted to just preserve the existing logic, rather than expand scope any further. A failed index lookup really is just an extension of changeset corruption, which is not really this PR's problem to deal with.