Add tests of non-deterministic behaviour

[glyn]

Tests are needed to cover the lack of deterministic ordering of objects. The preferred approach is for such tests to include a set of possible results, any one of which is valid.

[glyn]

(The following is a summary of a discussion in PR #60.)

@f3ath wrote (with terminology adjusted to align with RFC 9535):

Have we considered adding a flag (e.g. "non-deterministic": true) to allow arbitrary order of the result array instead of trying to list it in every possible order?

As @gregsdennis pointed out in PR 60, the RFC does not allow arbitrary non-determinism in the ordering of the nodelist resulting from a query. (The Working Group discussed increasing the non-determinism in that way, but decided against it.)

Table 6, table 12, and table 16 in the spec include examples where there is some non-determinism without there being arbitrary non-determinism. The limited non-determinism is typically produced by a combination of objects (which are unordered) and arrays (which are ordered) in the query argument.

I might not understand the idea fully, but if we want to allow non-deterministic order somewhere deep inside of the complex result object, we could maybe introduce a list of json pointers pointing to the particular elements of the result which are allowed to be non-deterministic.

I considered that possibility, but it's hard to specify simply and each implementation that wants to run the CTS would need to implement it correctly. The approach I chose in PR #60 is for non-deterministic tests to list all the allowable result arrays, so implementations simply need to check that the result array is in the list. The burden then falls on the writers of the CTS to correctly list all the allowable result arrays, which isn't too difficult for small examples.

(Another potential approach is to generalise an implementation of the RFC so that it produces a list of all the allowable nodelists and then to use that to prime the CTS. This could be done in Haskell, for example, by using the "list monad", but it wouldn't be trivial.)

/cc @cabo