Change how we store and sign/zero extend integers.

Previously we stored raw `u64`s and expected the user to remember
that they needed to zero/sign extend the underlying integer whenever
they wanted to do anything with that. We did not always do this, and we
did it incorrectly in a couple of places!

This commit introduces a new struct `ArbBitInt` which is basically a
pair `(bit_width: u32, value: u64)` which hides the underlying value. To
get a raw Rust-level integer you have to call a method, and those
methods have names with `sign_extend` and `zero_extend` in them. While
one can, of course, call the wrong one, it is now impossible not to
sign/zero extend. This struct is currently rather simple, but the API is
flexible enough to extend to beyond-64-bit ints transparently. The
(fairly extensive) test suite is a bit overkill right now, but is
intended to help give us confidence if/when we support more than 64 bit
ints in the future.

This commit also necessarily requires a full audit of everything to do
with ints-in-traces. That means a lot of code churn, but it's absolutely
necessary, and (a) makes much clearer where we should sign/zero extend
(b) catches some places where we didn't do this but should.

This commit isn't perfect. In particular, I'm not very happy that
`Const::Int` has both a `TyIdx` that contains a bit width *and* an
`ArbBitInt` that separately records a bit width. That feels icky, but
doing something neater will require at least some ickiness elsewhere.
I'll worry about that another day.

ykrt/Cargo.toml

@@ -58,3 +58,4 @@ lazy_static = "1.5.0"
 lrlex = "0.13"
 lrpar = "0.13"
 regex = { version = "1.9", features = ["std"] }
+proptest = "1.6.0"