Clarify initial XPath expression context of bind expressions (and similar)

This issue is intended to capture the outcome of some discussion with @lognaturel about [this test](https://github.com/getodk/web-forms/pull/135/files#diff-d5fa331b36b24330881c9159c3b8b1ad1027ff1aa89a4f2000404e01b18c0d20R459). Specifically, given a form structure...

```xml

Some form



1
2
3
4
5

```

- In JavaRosa, the value of `/data/node-values` will be `"345"`
- Currently in Web Forms, it will be `""`

This is because:

1. Web Forms evaluates all XPath expressions with a single node as its expression context.
2. For each `/data/node`, the expression `position() > 2` will always return `false` because `position()` in a single node context will always return `1`.
3. As a result, none of the `node` repeat instances will ever be relevant.
4. That non-relevance is inherited by each `value`, causing their values to be blank.

It's clear that the expectation is that the `relevant` expression is evaluated against a multiple node context. Though it's not obvious in this form fixture, there's still some room for ambiguity about what the expected context should be:

- The _complete set_ of all nodes matching the `nodeset`
- The _contiguous subset_ of all nodes matching the `nodset`

The first option seems obvious. But consider a variation of the above form fixture:

```xml

Position, context, nested repeats





1
2
3
4
5





1
2
3
4
5

```

- With the _complete set_, the respective values of `/data/outer/inner-vals` would be:
- `"345"`
- `"12345"`

- With the _contiguous subset_, they'd be:
- `"345"`
- `"345"`

The latter is what I would intuitively expect. Describing a structure like this in discussion with @lognaturel, we agreed on that intuition. Notably, for the affected test linked above, the _implicit_ outcome would be that `position()` in `nodeset` context will behave as if it had been expressed as `position(.)` (i.e. it would be consistent with the ODK XForms specification's 1-arity `position` extension).

Having a clear set of expectations, we also agreed on these next steps:

1. Time box a spike to prove out the hypothesis that both form structures will behave as expected, with a **general change** to use the _contiguous subset_ context for:

- `relevant` expressions
- other bind expressions with the same `nodset` context
- broadly, any other form expression which would be expected to have the same `nodeset` context

2. Validate that this generalization does not break other things. (Editorial: it may very well fix other things.)

3. If all of the above holds, open an [xforms-spec](https://github.com/getodk/xforms-spec) issue to clarify initial expression context accordingly.

Start with the test linked from PR #135 and trace how Web Forms evaluates XPath expressions for bind nodesets. Validate the contiguous-subset context for relevant and related bind expressions using both form structures, then check that existing behavior is not broken and record the outcome for a follow-up xforms-spec issue.

Written by the indexing model from the issue text.