Based on the observation that rulesets can contain all types of Rule children.

There's no facility in the grammar to express quantifiers for simple rules, but
my thinking is to "flatten" rulesets into collections of simple rules with
quantifiers.

No support for actually using these yet.

We can now successfully access variables that are defined in the header of
start states or simple rules.

The way the code generation logic was phrased, references to local variables of
enum type would accidentally be considered members of the enum. With this
refactoring we now correctly treat these as references to locals. However,
things are still not completely correct because we never actually define the
local we are referencing.

Taking a leaf out of some academic literature, this commit implements a simpler
but more high performance state set implementation. It's essentially an open
addressed hash table with linear probing, but with the ability to expand the
capacity as it fills up. It's not very well documented in the source yet because
it's only half finished. We also need to parallelise the expansion and make it
thread-safe, but I think this is best postponed until we regain multithreaded
checking.

This also modifies a command-line flag and introduces a new one:

  * --set-capacity: This now specifies the initial size of the set that is
    allocated. That is, if you pass 'x', a set size will be allocated such that
    when full it will occupy 'x' bytes. This is perhaps counterintuitive and
    maybe we should consider renaming this flag.
  * --set-expand-threshold: The percentage occupancy at which we consider set
    insertion inefficient and choose to expand the set.

TODO:

  * Option to set "never" for --set-expand-threshold. This would just terminate
    when we fill the set.
  * More precise initial capacity calculation. See the FIXME around this.
  * Parallelisation of the expansion logic.

With these changes long-running2 is checkable using --set-capacity 8589934592
--set-expand-threshold 100 in 79 seconds on a single core. It is actually slowed
by hitting swap on the machine I'm on (synecdoche). It looks like we could do it
closer to 45-50 seconds without touching swap.

By using a proper hashing function we get a fairly dramatic speed up. This now
makes checking long-running2 practical. We get 453 seconds on our current
representative platform. Note, this is still single-threaded.

This commit contains sources from xxHash v0.6.5. xxhash.c from that release has
been pasted into xxhash.h so that we can emit the checker as a single source
file.

This -- combined with an upcoming change to a more practical hash function --
results in fewer hash collisions and thus vastly improved performance of
set_insert.

This saves us having to do an extra allocation during insertion into the state
set, speeding up checking by ~20%. Checking is still extremely slow, but this is
just an obvious piece of low hanging optimisation fruit.

We now generate the checker itself as C, rather than C++. My current intuition
is that we can beat the speed of the C++ checker by moving to C. By making our
operations more transparent to the compiler we should be able to (a) move type
checking to Rumur and avoid some coercion hell in the checker as well as (b)
essentially force devirtualising all function calls.

Note that this commit drops a significant amount of functionality:

  * TBB support
  * Useful state hash (to be reintroduced later)
  * Multithreaded support (to be reintroduced later)
  * Support for a fixed-size seen set
  * Support for a fixed-size queue

Still not sure this is a feasible way to go, but seems to work so far.

We're about to introduce some code that uses std::index_sequence. I'd like to
get by without this, but for now it seems the simplest way forward.

We were assuming the existence of zero_based_value.

Turns out when disabled this triggered a compile-time error instead of correctly
switching off generation of certain methods. I *think* we've got it right now
(why can I never remember how enable_if works?). We also fix an issue where the
other operator[]s weren't being inherited.

It turns out if you inherit copy assignment operators from a parent class, they
don't count as copy assignment operators for you. Specifically, assignments that
would call the copy assignment operator will still try to call it and may
consider if deleted if you've, e.g., implemented a copy constructor.

Closes Github #1 "array references cannot be assigned"

What...? Why were we allowing one literal to be assigned to another?

This fixes a problem where dealing with arrays of booleans (or booleans within
the state in certain scenarios) resulted in generated code attempted to use
Boolean::reference_type which we had neglected to define.

This triggers compile errors because we don't currently define a reference type
for booleans.

Related to Github #1 "array references cannot be assigned"

Related to Github #1 "array references cannot be assigned"

We should really convert this to a manpage instead.

This commit introduces a new command line option, --tbb, that enables the use of
Intel Thread Building Blocks' tbb::concurrent_unordered_set for the
multithreaded checker. For our current work horse, long-running2, this appears
to make no discernible difference in its runtime characteristics. However, I've
still committed this because it's relatively low overhead and I wonder if it may
prove useful on future models.

This checks that we won't run afoul of a problem wherein we end up with an
object with a zeroed vtable. See the comment that was deleted in this commit for
details.

Related to Github #7 "Fixed set capacity requires 64-bit addressing"

This was no longer gaining us anything.