[XSLT] Composite merge keys

[michaelhkay]

The changes in PR #1674 to allow composite sort keys automatically propagate to xsl:merge, because the semantics of xsl:merge-key are defined entirely by reference to xsl:sort.

No immediate problem, except (1) we should acknowledge the fact and point out that composite merge keys are now allowed, and (2) the effect on the current-merge-key() function. This is the sequence-concatenation of the merge keys for multiple merge sources. The spec says:

the [current merge key] will be a single atomic item if there is a single merge key, or a sequence of atomic items if there are multiple merge keys.

Actually I think that's already wrong, because it forgets that an individual merge key may be an empty sequence. If that happens then the current-merge-key() function is somewhat useless. I suggest we simply document the fact: if there are multiple merge sources generating multiple merge keys and they are not all singletons, then the sequence concatenation of the merge keys may not be especially useful.

We could provide a variant current-merge-key-array() that returns an array of sort key values, one for each xsl:merge-key element, each one being a sequence of atomic items.