Now we can do things like:

# copy-paste from output
ring.<t,L,tie,Cn,M,Ln,I,D,J,Rn,A,K,F,G> = QQ[]
ID = ring.ideal(L - (1*Cn*t),tie - (1*Ln*t),Cn - (1*I + 1*J),M - (1*t^2),Ln - (1*D + 1*L + 1*M),I - (1*Rn*t),D - (1*Rn*t),J - (1*Ln*t),Rn - (1*F + 1*G + 1*K),A - (1*tie),K - (1*t^2),F - (1*Ln*t),G - (1*Cn*t))

# we are interested in tie in terms of t; so we want to remove anything not these two:
ID.elimination_ideal([L,Cn,M,Ln,I,D,J,Rn,A,K,F,G])

# output from this SageMath command is
# Ideal (t^3 + 2*t^2*tie + t*tie - tie) of Multivariate Polynomial Ring in t, L, tie, Cn, M, Ln, I, D, J, Rn, A, K, F, G over Rational Field
# which we can solve for tie to get tie = t^3/(1-t-2*t^2) just as expected

Add monadic bind combinator h_bind

Free res_unamb

Add some missing type conversions to make h_read_bits work with count>32

Descend properly in h_seq_index_path

Fix #118

H_VALIDATE_APPLY macro

NEWS:
* Switching endianness mid-byte no longer potentially re-reads bytes.
* bit_offset now consistently refers to the number of bits already
  read.
* HParsedTokens now have a bit_length field; this is a size_t.  This
  may be removed for memory reasons.

The bit writer has not yet been updated to match; the result of
switching bit writer endianness in the middle of a byte remains
undefined.

I've found this especially useful in combination with my own
_attr_uint_const for things like flags and type specifiers.

It's possible that its usefulness might be diminished significantly if
there were a built-in bitfield constant parser -- that certainly would
eliminate all of my current uses of it -- but it still seems nicely
symmetric with H_ACT_APPLY.

Tabs after the first non-tab character are crazymaking. I picked 8
because it wasn't 7 and caused the backslashes to line up on
H_ACT_APPLY.

llvm doesn't care about your size

Fix compilation when PKG_CONFIG_PATH is not in environ

Remove vacuous states in base64_sem?.c

Move backend names into src/benchmark.c

They apparently removed alloc_size at some point (it was a no-op
beforehand), causing the attribute to throw an error when clang compiles
anything including allocator.h.

I don't think these actually affect correctness since there's no way for
0x40 or 0x60 to show up in a parse tree anyway, but they're confusing.