Simplify ZipLongest implementation

[viceroypenguin]

The various Zip* methods currently share implementation in .ZipImpl(). However, the code is simpler for each one when they are written separately; that is, in this case, the variances are more than the commonality. As such, we should allow each method to be implemented separately.

This PR updates the implementation of ZipLongest to be done separately from .ZipImpl().

[viceroypenguin]

NB: Depends on #901.

[atifaziz]

Possibly a duplicate of PR #715 by @Orace?

[viceroypenguin]

Duplicate in the sense that both separate the implementations of the three zip functions, yes. However, #715 uses T4 to generate separate implementations of each method for argument count 2-4. Also, #715 and #905 have very different implementations (subject to debate which is better).

• Zip refactoring #715 keeps the TryRead method to play nice-nice with non-conforming enumerables and hide complexity
• Simplify ZipLongest implementation #905 is ultimately simpler, but relies on enumerables to allow repeated .MoveNext() after enumerable is complete.

[Orace]

Some thoughts about this:

• In Zip refactoring #715, the TryRead method should be moved to EquiZip.g.cs as a private method.
• The used pattern probably wastes resources. It's implemented for 4 sources, and for other cases, it uses dummy sources and discards values with a lambda (resulting to memory allocation that can be avoided):

  MoreLINQ/MoreLinq/ZipLongest.cs

  Line 66 in 3d36039

  return ZipLongestImpl(first, second, Enumerable.Repeat(default(object?), int.MaxValue), Enumerable.Repeat(default(object?), int.MaxValue), (a, b, _, _) => resultSelector(a, b), 2);

  
  It will not scale well if we want to add overloads with more sources.
• Calls to .MoveNext() after an enumerable is complete should be avoided. Moreover this is tested with TestingSequence

  MoreLINQ/MoreLinq.Test/TestingSequence.cs

  Lines 93 to 98 in 9c17aae

  	enumerator.MoveNextCalled += (_, moved) =>
  	{
  	Assert.That(ended, Is.False, "LINQ operators should not continue iterating a sequence that has terminated.");
  	ended = !moved;
  	MoveNextCallCount++;
  	};

[viceroypenguin]

Some thoughts about this:

• The used pattern probably wastes resources. It's implemented for 4 sources, and for other cases, it uses dummy sources and discards values with a lambda (resulting to memory allocation that can be avoided):

  MoreLINQ/MoreLinq/ZipLongest.cs

  Line 66 in 3d36039

  return ZipLongestImpl(first, second, Enumerable.Repeat(default(object?), int.MaxValue), Enumerable.Repeat(default(object?), int.MaxValue), (a, b, _, _) => resultSelector(a, b), 2);

I did do some testing, and while the memory usage is negligible (400b vs 176b), it does cost an additional 30-50% to do it the #905 way. Probably has mostly to do with the extra MoveNext calls being done on the dummy enumerables. 🤔

It will not scale well if we want to add overloads with more sources.

Not sure that this is a concern. Asking for more than 4 enumerables to be zipped together seems a little excessive, and should probably be solved by the person requesting it.

• Calls to .MoveNext() after an enumerable is complete should be avoided. Moreover this is tested with TestingSequence

  MoreLINQ/MoreLinq.Test/TestingSequence.cs

  Lines 93 to 98 in 9c17aae

  	enumerator.MoveNextCalled += (_, moved) =>
  	{
  	Assert.That(ended, Is.False, "LINQ operators should not continue iterating a sequence that has terminated.");
  	ended = !moved;
  	MoveNextCallCount++;
  	};

Already discussed and addressed in #901/#936. I won't repeat the discussion further here.

[viceroypenguin]

Hey @Orace, I took your idea and managed to improve performance by another 10-20%. Feel free to take a look at the updated TryRead() and code gen. It's Scriban instead of T4, but should be easy to translate, I hope?

Closing this PR in favor of an updated #715.