unsigned integers for sizes of things

[andrewrk]

Arguments in favor of signed integers for array sizes:

• Fix underflow in core::str::Searcher::new rust-lang/rust#16590 (comment) in short, if the array size is 10 and you subtract 20 you get undefined behavior.
• Many POSIX functions return ssize_t (such as read) because they want -1 to mean an error. This means that all that space needed by unsigned isn't needed for these. Why stop there? How about the maximum size of things is @max_value(isize) rather than @max_value(usize).
• POSIX printf returns int. Negative is error, positive is byte count printed. We want a similar thing, but we'd probably use isize.
• Iterating backwards to 0 for unsigned integers is tricky.

Arguments in favor of unsigned integers for array sizes:

• Array lengths don't really have a sign. They can't be negative. So unsigned is more correct.
• 2x the maximum value. On a 32-bit system, byte arrays would be limited to 2GB in length for signed size.
• Manual assertions/checks needed when an unsigned number is expected. (assert(num_bytes_to_print >= 0);)
• Passing a signed number to an unsigned type in C (e.g. size_t) requires a cast.

[andrewrk]

Jury's in, we're going to use isize as the type for sizes of things.

If you need a 4GB byte array on a 32-bit system, use raw pointers + usize.

[andrewrk]

implemented in ae2151a

[andrewrk]

Changing stance on this. We're going back to usize. Additional reasons:

• We ran into some awkward casting situations that made usize seem easier to use.
• The rust issue linked above actually is solved in zig with debug safety turned on for integer overflow.