A bit more robust and portable.

It seems the set of architectures with a double-word compare-and-swap and
compiler support for this is roughly only x86. Instead of trying to dance around
every other architecture that doesn't have this support, just don't run this
test on other architectures. This reverts part of
6d918427.

Knowing that `|` in Murphi maps to `||` in C, we swap the order of the
conditionals in the forall test cases to *really* force an undefined read if the
entire expression is not optimised to `true`.

The implementation of this was relatively straightforward, but threw up a last
minute surprise. Simplification happens first *within* the quantified expression
with access to the constraints on the quantified variable. So, even without
explicit support for forall expressions, the following expression:

  forall x: 1 .. 2 do x = 1 | x = 2 end

will get simplified to

  forall x: 1 .. 2 do true end

We still need explicit forall support to collapse this resulting expression into
`true` and enable further simplification.

Note that this commit does not yet support custom steps in forall expressions.

This fixes an issue where malformed SMT problems would be produced from
expressions within quantified sections. The quantified variable would be
declared using the ID of the quantifier, but then references to it would use the
ID of the quantifier's contained declaration. As a result, SMT solvers would
reject the problem for referring to an undeclared variable.

This bug was actually identified while trying to implement forall support in the
SMT bridge. The upcoming tests for this provoke the bug.

Debian auto builder testing of v2020.01.11-1 exposed that we incorrectly attempt
pointer compression when using the x32 ABI, under which pointers are 32-bit. We
now only compress when on Linux x86-64 targeting the standard ABI.

While the ARM ISA has support for double-word atomic compare-and-swap,
apparently compilers do not implement the instructions for this. So in this
scenario we need to link against libatomic and suppress the lock-free tests from
the test suite. This was noted during Debian's auto builder testing for
v2020.01.11-1.

When using UTF-8 characters in an input to xxd.py, multi-byte characters would
result in invalid code generation. We now support any arbitrary bytes in the
input file. Though none of the resources we translate with xxd.py currently
contain multi-byte characters, this allows us to use them in future.

This generated header is not seen automatically by CMake, so needs to be
explicitly listed. Prior to this commit, we were not installing it which led to
a broken installation. I.e. `#include <rumur/rumur.h>` would not work in user
programs.

Github: related to #180 "negative literals cause malformed SMT problems"

Github: closes #180 "negative literals cause malformed SMT problems"

Github: related to #180 "negative literals cause malformed SMT problems"

When libraries are installed at non-standard paths they use these variables to
notify C++ compilers of their locations. It seems CMake's find_path() does not
listen to these by default though. So now we explicitly make them available
during searches.

Github: related to #158 "pack state struct"

While packing saves a significant amount of memory, it also has a non-trivial
negative effect on runtime. Some users may want to prioritise speed over memory,
so we now give them the opportunity to choose.

Github: closes #158 "pack state struct"

As discussed in the previous commit, compilers apparently cannot easily see this
for themselves.

This peculiar sequence which checked a condition and then asserted the opposite
of it inside the branch seems just plain wrong. We are probably lucky compilers
did not take advantage of the conflicting condition and assumption and conclude
this was dead code and remove the entire function. The remaining
assertion/assumption should now be usable by the compiler.

As far as I can tell, this was broken since this code was first written in
commit 7d0a8b74.

This was picked up by building with warnings enabled but no optimisation. Clang
complains that the call to state_rule_taken_get inside __builtin_assume is
impure. This should not be true and I think Clang is wrong, though I'm surprised
it cannot see that read_raw() is pure. Naturally this only came in when we
started aggressively packing structure members, so would not have been noticed
previously.

This is to reflect changes that were made in
fe49bea9 and
fd04cb9c.

Now instead of finding the first available slot to put the migrating pointer in,
we pick the slot it immediately hashes to and shuffle all the other elements
along one. In theory this should be more efficient based on an XCHG being
cheaper than locked CMPXCHG.

Github: closes #179 "replace cmpxchg with xchg during set migration"

This somewhat optimises the set migration process, by taking advantage of the
fact that it is fine to write a tombstone to a previously empty slot.

Github: related to #179 "replace cmpxchg with xchg during set migration"

We no longer need this now that we use a sentinel value for tombstones. This
effectively reverts 27484ac4,
f6df1732,
c6a04034, and
50cff5ae.

We never actually need to recover the original pointer from a tombstone. We can
take advantage of this to just use a sentinel value (-1) to represent a
tombstone. This should speed up any testing against or setting of tombstones,
but it also removes alignment requirements we have on the state struct.

These syscalls are used on i386.

Github: closes #178 "sandboxing broken on Linux i386"

This was previously emitted as a 0-element array in this scenario. While this
did not enlarge the state struct, it forced its alignment to be >= 8 bytes. By
removing it entirely we can reduce state struct alignment to 1 byte on x86-64
Linux and 2 bytes on other platforms. The overall aim here is to enable the
state allocator to more efficiently allocate states in memory.

Github: related to #158 "pack state struct"

Github: related to #158 "pack state struct"

Github: related to #158 "pack state struct"