Github: related to #169 "returning type-compatible but differing range from a
  function is rejected"

We were rejecting functions that returned values of range type when the type of
the returned expression was not directly a range. This could happen when the
type of the returned expression was a TypeExprID that then resolved to a range.
We now accept such constructions.

Github: closes #169 "returning type-compatible but differing range from a
  function is rejected"

Github: related to #169 "returning type-compatible but differing range from a
  function is rejected"

Cirrus CI seems to run the builds in the order in which they are declared. By
declaring them in descending order, we get to see failures on later FreeBSDs
earlier which seems like the right prioritisation.

Cirrus CI recently added the ability to use the GCE option --image-family
instead of --image [0]. This seems to be the way forward, so switch to using
this exclusively.

  [0]: https://github.com/cirruslabs/cirrus-ci-docs/issues/422

This avoids the messy scenario where the build attempts to run the test suite
even when compilation itself failed.

This lets you more easily run only the tests for rumur or only the tests for
rumur-ast-dump. This will become useful as we move to having another binary, a
preprocessor, in the mix soon.

Filename's like `a quote: " <-` would have caused invalid XML to be generated
previously.

We now *always* have a filename attribute on the unit tag.

We now have full model content when piping in a model from stdin as well as when
the model arrives via a file.

It seems the stream that is used for parsing is unusable afterwards. Flex or our
own code has caused failbit to be set. Instead of trying to undo this, simply
use another stream. We'll make use of this for replay in an upcoming commit.

This is part of work towards including the input model content with the AST
produced by rumur-ast-dump, regardless of whether the model is provided in a
file or on stdin.

This was intended to be a parent of master already, but I seem to have somehow
fouled this up in a previous packaging cycle.

Github: closes #168 "add xmllint and an SMT solver to FreeBSD testing"

This is required to run the ast-dump tests.

Github: related to #168 "add xmllint and an SMT solver to FreeBSD testing"

When building in debug mode, the user could trigger an assertion failure by
setting a value type that was too small to contain values in the model. Note
that this would *only* occur when the user specifically overrode --value-type
with a narrower type than the one that would have been selected automatically.

Github: closes #166 "users can force verifier assertion failure"

We're about to introduce a new error case in these functions.

Github: related to #166 "users can force verifier assertion failure"

If value_t is chosen to be an unsigned type, comparisons like `v < 0` cause
warnings with -Wtype-limits. We also need to work around a -Wsign-compare bug in
this change.

Github: related to #163 "reverse for ranges don't work"

We should now have full support for incrementing by negative amounts within a
quantifier.

Github: closes #163 "reverse for ranges don't work"

The lower bound may be above the upper bound if the user has described a down
counting loop. These aren't properly supported yet, but it is an aspiration.

Github: related to #163 "reverse for ranges don't work"

This is a bit of a happy accident here. I thought we were explicitly requiring
the step of a for loop to be a generation-time constant, as CMurphi does.
However, it turns out we were actually constant folding the step during
validation, and as a side effect throwing an error during constant folding when
we encountering something non-constant.

This commit fixes validation to only attempt constant folding of the step when
it is actually foldable. We still need some generated validation checks for
loops that have dynamic bounds and/or steps.

Note that it is not yet possible to construct such a thing because validation
rejects for-loops with steps that are not generation-time constants.

Github: related to #164 "loop iteration code incorrect"

Github: related to #164 "loop iteration code incorrect"