smarter semantics for right shift by comptime_int

[thejoshwolfe]

When the shift amount of a right shift is not comptime known, everything makes sense. However, I discovered in #1543 and discussed in #1530 (comment) that there are cases for shifting by a comptime_int that would be nice if they "just worked". For example, right-shifting a u8 by 8 should result in 0.

More generally, right-shifting a @IntType(false, N) by M will always fit in a @IntType(false, N - M). For example, a u32 right shifted by 30 will always be < 4. The extreme case where N == M means that the result of the shift will fit in a u0, in other words, the value is 0. For example, right-shifting a u32 by 32 should just be 0.

Even though the result of this shift is guaranteed to fit in a smaller integer type, that doesn't mean we should make the expression be of that type. For example, it would be surprising if an implicitly typed var was a smaller type than you expect.

fn foo(x: u32) u32 {
    var result = x >> 16;
    result += x << 16;
    return result;
}

result was probably meant to be a u32, so we don't want it to get declared as a u16. If it's a u16, at least you will get a compile error that the u32 resulting from result + x << 16 doesn't fit back into result.

Here are some scoped-down ideas that are easier to reason about. Which of these sound like good ideas?

1. Right-shifting a @IntType(false, N) by comptime-known N results in 0.
2. Right-shifting a @IntType(false, N) by comptime-known value at least N results in 0.
3. Right-shifting a @IntType(true, N) by comptime-known N - 1 results in -1.
4. Right-shifting a @IntType(true, N) by comptime-known value at least N - 1 results in -1.

One concern here is that values that are accepted at comptime are not accepted at runtime. Curently, you have to shift a u32 by a u5, and 32 is not representable as a u5. We would have different rules for comptime-known values and runtime values.