Spec indicates that XPath node unions are supported but it seems that they aren't

I'm not sure if the solution is to change the spec, or to implement this support. So for now it's just a problem statement!

As [stated here](https://github.com/getodk/xforms-spec/blob/80caf007621ff127e3a482b4a6e1c551bdbfc747/_sections/30-bindings.md?plain=1#L88):

> All [XPath 1.0 operators](https://www.w3.org/TR/1999/REC-xpath-19991116/#exprlex) are supported, i.e. |, and, or, mod, div, =, !=, <=, <, >=, >, +, -.

Create a XLSForm like so (note the escaped pipe is new syntax not yet in pyxform):

```
| survey | | | | |
| | type | name | label | default |
| | text | q0 | Q0 | ../t2 \| ./t4 |
```
Which generates this XForm:

```

pyxform_autotesttitle
















Q0

```

Give the XForm to ODK Validate and it says:
```
>> Something broke the parser. See above for a hint.
org.javarosa.xpath.XPathUnsupportedException: XPath evaluation: unsupported construct [nodeset union operation]
```
The error comes from the Javarosa [union expression handler](https://github.com/getodk/javarosa/blob/e83ca2d04fe8f536875208ad420f9266efeb0ba0/src/main/java/org/javarosa/xpath/expr/XPathUnionExpr.java#L36).

Dimagi/CC [does the same thing](https://github.com/dimagi/commcare-j2me/blob/9f8df9c30693b7ad0727a6dbbff6a60ae6ef0a47/javarosa/core/src/main/java/org/javarosa/xpath/expr/XPathUnionExpr.java#L22) and their spec doc says the same thing (union supported).

ODK Collect docs allude to unions [here](https://docs.getodk.org/form-operators-functions/#repeat-groups):

> Nodesets can also be created by joining two or more nodes with pipes: /data/age | /data/name.

Only reference I could find about union support was in relation to adding the `randomize` functions: https://github.com/getodk/javarosa/issues/273

Start with the XPath operator statement in _sections/30-bindings.md and reproduce the example by generating the shown XForm and running it through ODK Validate. Inspect the linked JavaRosa union expression handler and related references to determine whether the specification or implementation is inconsistent. Done means the supported behavior is resolved and the spec or implementation is updated accordingly.

Written by the indexing model from the issue text.