Pathlib is Python 3.4 only and there's at least one environment I want to test
in that still does not have 3.4 available.

See comment in this model for the purpose.

Amazingly we'd somehow never tested a basic invariant until this point. Turns
out emitted code was always invoking invariants incorrectly.

Fixes Github #24 "Duplicate resulting start states leak memory"

This suppresses the warning resulting from the only startstate in your model
being within a ruleset.

Seems like the user should be free to omit a startstate if they really want to,
even though it leaves them with a degenerate model.

We now have a first approximation of a working ruleset implementation. Basic
functionality of a rule nested within a ruleset is there.

Some todos to think about:

  * The emitted loop for a ruleset parameter can result in integer overflow in
    the case when the type being covered has a maximum value of VALUE_MAX.
  * There is no support as yet for startstates or invariants nested within
    rulesets even though the grammar supports this.
  * I have not yet tested '0 TO 10 BY 2'-style quantifiers.
  * I have not yet tested multiply-nested rulesets.
  * I have not yet tested colliding identifiers in quantifiers.

Smart pointers just confuse ownership in these cases. This reverts commit
84cb6dc9.

One further step towards ruleset support.

As usual, I'm bothered by the noisiness of shared pointers. Difficult to tell
whether the juice is worth the squeeze.

This is still not sufficient to handle rulesets, but progress.

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.