We'll need to adjust this once the checker goes multithreaded, but for now this
is the correct behavior.

Fixes Github #27 "failing an invariant results in exit with success"

I had misunderstood something while writing this code and thought that both
keywords and identifiers were case-insensitive in Murphi when in actual fact
only the former are. This is the first bug fix in a while that came down to
literally "delete some code".

Closes Github #25 "case sensitive identifiers"

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.