Simpler InDocumentOrder implementation.

[JonHanna]

System.Xml.Linq.Extensions.InDocumentOrder() uses a copy of the implementation
of System.Linq.Enumerable.OrderBy(), to copy that working implementation
without having a dependency on System.Linq.

This includes unused complications; supporting key-selection but only ever
using identity, part of the support for CreateOrderedEnumerable (but
incomplete, and if it was it would have no real effect as the ordering is
total), other comparers though only one is ever used, and a generalised
buffering approach that isn't shared with any other code and so gains nothing
in being generalised.

This commit replaces that with a more narrowly focused implementation,
providing just what is used by InDocumentOrder, resulting in simpler and
tighter code.

Obsoletes issue #3008 in that the case it is concerned with now results in an
immediate return from early in the call to CompareDocumentOrder(), so the
suggestion in #3008 would not improve performance further.

[ghost]

Going by this discussion: dotnet/coreclr#1329 (comment), you probably have right to put your initials after copyright and purge Microsoft, if you don't work for Microsoft.

[JonHanna]

I did start with the file that got deleted in this (git doesn't show that well unless there's a commit that only moves a file), so its definitely a derived work that started with something copyright Microsoft, and hence they are a copyright-holder on the derived work. The changes are pretty substantial if measured as a percentage of the file, so even when not listing all contributors (as is not done on this project) one could make an argument for adding me as a listed copyright holder on the file, but not for replacing MS entirely, as far as I can see.

[kangaroo]

There is precedent for adding yourself. I've done it in coreclr :)

[JonHanna]

@justinvp I'd thought of using Array.Sort, but figured that there must have been some reason OrderBy was favoured, so went with the path of just cutting down the implementation there to what was actually used. Having slept on it, I think the reason for OrderBy was simply that when one has the dependency on System.Linq, it's a simple one-liner to use. The only other advantage I can think of is that if OrderBy was ever improved then so would that be (e.g. the sort of thing I suggest in #2401) but that doesn't apply once the dependency is broken, so really Array.Sort is the way to go.
A further advantage is that I imagine (but don't know) that this is often called in cases where the nodes are already sorted but the calling code needs to guarantee that, and Array.Sort's introspective use of insertion sort for small partitions should serve better there.
A theoretical downside is that the sort is no longer stable, but the ordering applied here is total in any case, so the only case where stability would affect anything is duplicate references, in which case the effect cannot be observed.

[stephentoub]

Could this just be return items; after the end of the if block? I'm wondering if it needs to be an iterator at all.

[Eyas]

items.Length >= count, so this could only be done if count == items.Length, no?

[stephentoub]

Though thinking about it further, without more work that would move the ToArray work to be done during the initial call rather than during the first MoveNext. Ok, let's leave it as is.

[JonHanna]

Yeah, I considered that, and decided against it for those two reasons, and also that if we're avoiding returning objects from linq methods that implement IList when it would be potentially uesful, we should probably also avoid doing so when it's mostly a shortcut.

[stephentoub]

LGTM.

@krwq, any concerns?