Terms as in "defined terms".

Mostly for subcommands followed by arguments or other subcommands. Which
are defined terms themselves, but still not handled.

e.g.: "reconnect device         kick connection from device side to ..."

In terms of regression delta, census:

- adb: ok, it motivated this change
- chown: not ideal, examples with chown itself are scoped. but acceptable.
- npm: idem.
- dpkg: not cool, I should limit term sequences to 3-4 terms

Some unhandled cases in adb, chown and npm,

- reveal the single_2_space variable does't work
- show a need to treat definitions that do \n after the terms

I was debugging a problem that didn't exist 😱

It's like it doesn't properly use all the {{long_space}} cases (newline
and single_2_space)

But it's kinda weird because in

 forward --remove LOCAL

it scopes the LOCAL but skips the --remove.

I guess this skip happens in the option-def+space context? Anyways,
worth running the syntest debugger on.

But not today!

For ease of use. Other X is less wrong but a little more unwieldy to
write and reason about.

To reflect the new change in KEYWORD_SCOPES' name

But I'm considering leaving the later unscoped, or any other 2nd term
after a keyword term.

Cause it causes regressions in other, more common commands, where it
scopes terms in examples. (As in every other delta in this commit)

And it introduces a hell of a regression in the Usage section of a few
other commands.

This is breaking for me, we'll probably do the 1st keyword only.

But this introduces quite a bit of regression. See syntax_test_cp

The shelcheck directive is explained here:
https://www.shellcheck.net/wiki/SC2148

To avoid inconsistent scoping in the usage/examples section of a bunch
of help messages.

But keep these scope assignations as comments, for future reference.

Only the "pair" bit.

This is all so overfitted, to suit adb's help message only, that it's
making me feel icky.

But, on the other hand, it's also a good census of all kinds of patterns
that we don't currently have a proper way to handle.

And if it doesn't add too many unnecessary scopes for other help
messages, I don't care much, I guess?

We're handling subcommand sub-tokens in an explicit manner, without
abstraction / generalization. At least for the time being.

Now we're scoping command keywords in usage lines so as to make them
coherent. Otherwise, some help messages show usage lines with and
without the command colorized.

I hoped to catch the tricky chown case with this, but I think I know why
it's failing: we do not `set: then-pop" in keyword-seq-def matches !!

As a side effect, we scoped "operand=VALUE" operands in dd, which is
nice.

As another side effect, we scoped "or:" usage lines in vim, which is bad
but easy to fix (next commit).

Cause it's an alternative connector in Usage lines

I hoped to catch the chown corner case with this but no such luck.

Instead, we caught a stray adb bug that I had forgotten all about (but
my syntax tests didn't :D ).

To harmonize with the following line, where "bat" is scoped.

This is very hacky but highlighting bat's help message properly is a big
priority for this syntax, as bat is our only playground.

Also renames the test file, cause it was incorrectly versioned 23.0.0

This change also has lots of side-effects.

ghc, ghci and tealdeer are ok

It leaves the jq in the "usage: jq ..." line not scoped, but it's
acceptable to me. Not like bat's case.

Cause keyword=VALUE looks pretty ugly if only the former is colorized.

I moved scripts/env.sh to ./utils in 57748ff and renamed the regression
diff functions from gdiff* to reg* in f8bf10d

Because it was matching the 2-space with the first lookahead, without
consuming the characters it matched. Then it matched the second
(negative) lookahead with the same 2-space. But because it's negative,
the whole match failed.

We just have to circumscribe the 2nd lookahead (negative) within the
first one.

This catches the 2 stray corner cases that I wanted to fix before
merging this branch: one line each in chown and npm.

But it also adds a hell of a regression in that it now matches plain
text from a lot of help messages. But this can be fixed easily enough,
cf. next commit.

The pattern we incorrectly matched was lines including some kind of
justified text, with ".  "

We can safely match this pattern out.