Regression tests demonstrating bugs with MLton.IntInf.fromRep.

Add a number of regression tests from MLton/mlton#65 that demonstrate
bugs with MLton.IntInf.fromRep accepting non-canonical integers.

Thanks to @robsimmons for the bug report and initial regression tests.
Implement IntInf.sign with a single (big) comparison.
Latent bugs in conversion of MLton IntInf-s to/from GMP mpz-s.

Fix a couple of latent bugs in conversion of Small IntInfs
(represented as an objptr with the bottom bit set to 1 and the top
bits representing a signed integer) to and from GMP __mpz_struct when
sizeof(objptr) > sizeof(mp_limb_t).
Additional regression test for MLton.IntInf.{rep,fromRep}.
Check IntInf representation invariants in MLton.IntInf.fromRep.

Both SML and GMP rely upon various representation invariants for
IntInf values.  For example, MLton's implementation of SML's
polymorphic equality on IntInf values assumes that if one argument is
a "small" IntInf and the other is a "big" IntInf, then the values are
not equal (implying that the values do not denote the same numeric
value); see commit 4a0163e.  Similarly, GMP assumes that the
most-significant limb of a non-zero mpz_t is non-zero (implying that
the _mp_size can be used to short-circuit a comparison and that all
limbs contribute to the string representation); see
regression/int-inf.rep3.sml and regression/int-inf.rep4.sml from
commit c0600c9.

When creating an IntInf via MLton.IntInf.fromRep, check that the
representation invariants are satisfied.  For a Big input, the checks
are essentially:
 * length >= 2  (* sign limb + magnitude limb(s) *)
 * v[0] <= 0w1  (* sign limb is 0w0 (positive) or 0w1 (negative) *)
 * v[l-1] > 0w0  (* most-significant limb is non-zero *)
 * value exceeds range of a "small" IntInf
For a Small input, the check is essentially:
 * value preserved by tagging and untagging

Thanks to @robsimmons for the bug report, initial regression tests,
and initial check logic.

Closes MLton/mlton#65.