Smaller memory footprint for BoundedArray

[whatisaphone]

This PR changes BoundedArray's len field from a usize to a minimum-sized integer. If you're keeping a million of these in memory, their size can add up.

BoundedArray(u8, 3) used to take 16 bytes, but now (with len stored as a u2) it only takes 4 bytes.

Notes:

• len is the only type that changed. I left all the usize parameters alone, to not break existing code. A new test was added, and the old tests were not changed.
  • The test is testing memory layout, which varies across targets, so I only let it run on x86_64. Not sure if that's the right approach?
• @intCast is sprinkled in. For each one, either the value had already checked before that point, or it's in an "assume" method.
  • appendNTimesAssumeCapacity is an "assume" method, but it had an assert inside. Am I right to think it's odd to mix assumes with asserts? Either way I left the assert as it was.

This PR message is now longer than the diff, oops. I'll stop rambling. Happy reviewing!

[andrewrk]

All these += @intCast(b) are actually 2 safety checks. This can produce better code if you do this instead:

x = @intCast(x + b);

[andrewrk]

Thank you! This is a nice enhancement.

[matklad]

@andrewrk this tripped a pretty bad bug for us in TigerBeetle:

tigerbeetle/tigerbeetle#1121

Essentially, we were doing size_of_something * (array.len + 1) and, with a tight integer bound, that + 1 now can overflow. We have tests to catch this in one instance, but I think there are more, and some are even sleepy bugs, where the size of the array in question is a comptime config value, so might not be tripped in the configuration we are testing with, but might trigger with some other configs. In fact, we were exceptionally lucky (or unlicky) here, as the length of array turned out to be 4 + 1 + 2 which is 2^3 - 1.

I don't think this is a problem with this change per se, as it all is very much reasonable. But it does seem that integer overflow semantics might need some extra work here.

[matklad]

Although I am wondering if it perhaps makes sense to do

len_repr: Len

pub inline fn len(self: BoundedArray) usize {
    return self.len_repr
}

in the meantime, so that the call-sites are more aware that something funky with integrer ranges might be happening here?

[andrewrk]

Reverted in 85747b2.