Clarify intentions around implied ordering of input set to aggregation transformations

The current specification, in several places, refers to the ordering of the input set, and defines rules around preservation of that ordering.

In most cases the input set is not ordered, and preserving the arbitrary order is meaningless and potentially onerous as it may require extra ordering of intermediate results.

This wording is used in operations like topcount which returns the top n values after applying an aggregate (i.e., count) to a field. This preservation of ordering was taken from $top and $skip in [Core], which requires a stable ordering of the results so that, if I do $top=10&$skip=0, followed by $top=10&$skip=10, and both the 10th and 11th orders have the same values for the properties specified in the orderby, I am guaranteed that I consistently get the same values for the 10th versus 11th record.

This same scenario isn't required for methods like topcount, however it may still be desireable to get consistent results when applying methods like topcount to entities that have the same aggregate value. However, rather than imposing a preservation of the order, we can follow the model of $top and $skip by simply saying that the service must guarantee a stable ordering across requests (for example, by adding the key fields to the ordering before applying the top) and not tie the ordering to the order of the input set.