Remove include/adt/mappingset.h, it's no longer used.

This and src/libfsm/internal.h's EXPENSIVE_CHECKS should move to a
common place later.

These symbols are exported in the library.

These rely on either direct FSM construction or setting captures via a
capture path, but captures are now implemented by a completely different
mechanism.

New tests will be added with the capture code in a future commit.

This is a big commit, unfortunately difficult to break apart
further due to interface changes, metadata being passed through
whole-FSM transformations, and so on. Sorry about that.

- Delete code related to capture action metadata on edges.
  That approach made FSM transformations (determinisation,
  minimisation, etc.) considerably more expensive, and there
  were some corner cases that I wasn't able to get working
  correctly.

- Switch to a somewhat simpler method, adapted from Russ Cox's
  "Regular Expression Matching: the Virtual Machine Approach".
  Since the capture resolution metadata (an opcode program
  for a virtual machine) is associated with individual end
  states, this combines cleanly when multiple regexes are
  unioned into a single large DFA that matches them all at once.

- Add lots of capture regression tests, mostly from using libfsm's
  `fsm_generate_matches` and a fuzzer to compare behavior against
  PCRE. This brought many, many obscure cases to light. The updated
  fuzzer harness will appear in a later commit.

Add a couple more execution modes to the fuzzer test harness.

In particular, add support for comparing match and capture behavior
against PCRE's -- because this depends on linking with libpcre, it's
disabled by defalut. Set `PCRE_CMP` in the Makefile to enable it, or
pass it as a build argument.

I'm adding this because many of the existing tests under
`tests/pcre-anchor/` and so on contain regexes that would now be
rejected as unsupported in combination with captures, but they are
testing cases unrelated to capturing.

There are several tests that have nothing to do with captures,
capture behavior is tested directly with `tests/captures/`.

We currently get the wrong capture result for it.

There were modifications to metadata associated with end states on both
sides. A few other changes will appear in separate commits.

Conflicts:
	include/fsm/fsm.h
	src/libfsm/consolidate.c
	src/libfsm/endids.c
	src/libfsm/merge.c

Now instead of exposing exactly how many captures the fsm has, we keep
track of the ceiling of the count, to track how large the capture buffer
needs to be. We could add this back if fsm_capture_count gets re-added.

Previously we doubled the buffer if it wasn't large enough, but
the next endid array may be > twice the size of the old buffer,
so we need to keep expanding until it's large enough.

We weren't saving the updated array size, so this could potentially lead
to repeated doubling and eventually allocation failures.

Also, change the assert for fsm_getendids's result -- if we get to
that point, it should always be found, not just not an insufficient
space error.

determinise: It's not possible to find a cached result in the hash
table without allocating a to-set buffer first, so assert that it
will be non-NULL.

fsm_findmode: This should never be used on a state without edges.

vm/v1.c and vm/v2.c: Free allocated return value on error.

For each pattern 0..n that will be combined, set an endid on them.
Then, generate inputs that match, and check that the endid result
on the single and combined FSMs are consistent.

In minimise.c, `split_ecs_by_end_metadata` does a first pass splitting
ECs based on their end data (like the name says). This sets which end
metadata should prevent states from starting out in the same EC,
effectively which states can/cannot be combined once minimisation's
analysis is done.

Previously, distinct sets of end IDs would keep states from merging, but
if epsilon removal and determinisation have led to end states with
distinct sets of end IDs, that alone shouldn't prevent them from merging
later -- the same end state just becomes associated with all those end
IDs. We do prevent states with distinct capture ID sets from merging,
but that's because of a few special cases like "^a(b)c$" and "^a(b*)c$",
where combining partially overlapping regexes' end states could lead to
false positives in the capture result.

Note: I added checking the program IDs (which was missing) to
`same_end_metadata`. This seems correct to me, but at the moment I can't
think of any test inputs that would lead to the same sets of capture IDs
but distinct sets of program IDs. I will see if fuzzing can find any.

This is tested by tests/endids/endids2_union_many_endids.c
and the new multi test in tests/capture/capture_test_case_list.c.

There were several unused store warnings about values that were only
set for logging, either `(void)x` them out or restructure the code
so that their scope is more limited.

Remove `next_offset` from `populate_solution`, since that isn't
being used at all. IIRC it was added before some of the path sharing
details made it unnecessary.

Also compare in the other direction, generating matching inputs from
the combined DFA and then check that individual regexes's captures
still match as expected.

This was set up to handle edge cases like `^(($)|x)+$` where there is an
alt with some nullable cases with anchors, surrounded by + repetition,
which turned up during fuzzing. This is an obscure edge case, it is
proving very difficult to handle correctly, and there is probably little
value in actually doing so.

Now we are flagging it as an unsupported PCRE construct in
ast_analysis.c's analysis_iter_repetition, so the code using
repeated_alt_backpatches is unreachable. Just remove it.

Strictly speaking this shouldn't include nodes that have been flagged
with `AST_FLAG_UNSATISFIABLE`. I have re-fuzzed with this changed and it
does not seem to have introduced any new issues. `active_node` is only
used in one place.

Rather than commenting throughout to note that .cont is the greedy
branch and .new is non-greedy, just rename them.

Addressed some merge conflicts to fuzz/target.c.

`expr->u.literal.c` is signed, so when negative casting it to `uint64_t`
can lead to a 64-bit value > 255. Clamp it to 8 bits.

EFENCE breaks CI builds that (correctly) do a zero-size allocation when
calling `calloc` with a count of zero, reporting that it's a likely bug.
Use a size of 1 instead of 0 to silence it.

The comment says this handles a .b that is EMPTY, but the recursive
call rejects it. Something in PCRE suite in CI is triggering this.

The description says "Return where an item would be, if it were
inserted", but it was returning the last element <= rather than
the first element >=, then the call to `state_set_cmpval` later
was shifting i by 1 for that specific case. Handle it correctly
inside the search function instead. Two other all call sites
need to check whether the result refers to the append position
(one past the end of the array) before checking `set->a[i] == state`,
update them.

Add a fast path upfront: It's VERY common to append states in order
to the state array, so before we binary search each first compare
against the last entry (unless empty).

In -O0 this can become pretty expensive (~25% of overall runtime for
`time ./re -rpcre -C '^[ab]{0,2000}$'`), but when built with -O3 very
little overhead remains. I'm adding this comment because every time I
see this it seems to me like it should have `EXPENSIVE_CHECKS` around
it, but profiling is telling me it really doesn't matter.

This is a major hotspot when doing epsilon removal over large runs of
potentially skipped states (as might appear from `^[ab]{0,2000}$`).

Add a fast path for appending, which is also very common.

Extract the edge set destination search into its own function,
`find_state_position`, and add a `#define` to switch between linear
search, binary search, or calling both and comparing the result.
I will remove linear search in the next commit, but am checking this
in as an intermediate step for checking & benchmarking.

When I run `time ./re -rpcre -C '^[ab]{0,2000}$'` locally for -O3:
- linear search: 2.991s
- binary search: 1.521s

After the other changes in this PR, calls to qsort from
`sort_and_dedup_dst_buf` are one of the largest remaining hotspots in
the profile. We can often avoid calling qsort, though:

- If there is <= 1 entry, just return, it's sorted.

- Otherwise, first do a sweep through the array noting the min and max
  values. Unless there is a huge range between them, it's much faster to
  build a bitset from them in a small (max 10KB) stack-allocated array
  and then unpack the bitset (now sorted and unique). Only the needed
  portion of the array is initialized.

I have not done a lot of experimentation to find a cutoff point where
the bitset becomes slower than qsort (it may be much larger), I picked
10KB because it's likely to be safe to stack-allocate.

I tried changing the bitset unpacking to use an 8 or 16 bit mask and
jump forward faster through large sub-word ranges of 0 bits, but any
improvement was lost among random variation, so I decided it wasn't
worth the extra complexity. We already skip whole words that are 0.

If min and max are exactly 64 states apart the upper value was getting
silently dropped due to an incorrect `words` value here.

One of the patterns in the PCRE suite triggers this:

    ./re -rpcre '(?:c|d)(?:)(?:aaaaaaaa(?:)(?:bbbbbbbb)(?:bbbbbbbb(?:))(?:bbbbbbbb(?:)(?:bbbbbbbb)))' "caaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"

This should match, but did not.

determinise: It's not possible to find a cached result in the hash
table without allocating a to-set buffer first, so assert that it
will be non-NULL.

fsm_findmode: This should never be used on a state without edges.

vm/v1.c and vm/v2.c: Free allocated return value on error.

There were merge conflicts, which had to do with the return type of
idmap_iter's callback -- on `main` it was `void`, on the branch it was
`int` and indicated whether iterations should continue or halt. I picked
the `int` form, and updated `idmap_iter` so that it was actually
checked, because it probably doesn't make sense to continue iterating
when earlier steps have errored out.

- 'd' (default) no longer exists, it's now 'r'
- add 's', 'i', 'M'