Add QueryBuilder support for explicitly building SpanNearQuery and/or inOrder=true [LUCENE-8543]

`QueryBuilder` has historically built phrases according to the semantics of `(Multi)PhraseQuery` (which incorporates the concept of order, but allows for negative offsets in calculating slop/edit distance).

#9577 corrected a bug that substituted `SpanNearQuery (inOrder=true)` implementation for graph phrase queries despite the fact that for `slop > 0` the semantics of `SpanNearQuery (inOrder=[true|false])` differ from the semantics of `(Multi)PhraseQuery`.

Inspired by (but not related to) #9577, this issue considers the likelihood that there are some common use cases for which `SpanNearQuery` semantics may be preferable to the semantics of `PhraseQuery`. The distinction between the two is clearer for the `inOrder=true` case of `SpanNearQuery`, which disallows negative offsets in calculating slop/edit distance.

The logic for building `SpanNearQuery` is already present in `QueryBuilder`; perhaps `QueryBuilder` could expose that logic so that it can be leveraged in cases that explicitly desire `SpanNearQuery` (and associated semantics).

---
Migrated from [LUCENE-8543](https://issues.apache.org/jira/browse/LUCENE-8543) by Michael Gibney (@magibney)

Start in QueryBuilder and trace the existing logic that builds SpanNearQuery instances, then compare its behavior with PhraseQuery for slop and ordering. Determine how an explicit API for SpanNearQuery, including inOrder=true, should be exposed and verify that callers can request those semantics without changing existing phrase-query behavior.

Written by the indexing model from the issue text.