Signed literal construction should respect bit width constraints

[sandwichmaker]

Current, one can construct a literal s8:128, even though 128 cannot fit in a signed 8 bit integer. Infact what happens is that the bit pattern of 128 is used to initialize the s8 array and we end up with s8:128 == s8:-128. I believe this behavior is not allowed in Rust and should not be allowed in dslx either as it is highly unintuitive when reading code. Further it actually breaks from the type safety provided by dslx, where instead of treating 128 as an integer, we treat it as a bit pattern.

[dnmiller]

I was surprised at this. In fact, dropping the code

    let _ = assert_eq(s1:-1, s1:1);

into a test raises no errors from the interpreter.

[cdleary]

Note in Rust playground you get:

error: literal out of range for `i8`
 --> src/main.rs:2:17
  |
2 |     let x: i8 = 255i8;
  |                 ^^^^^
  |
  = note: `#[deny(overflowing_literals)]` on by default
  = note: the literal `255i8` does not fit into the type `i8` whose range is `-128..=127`
  = help: consider using the type `u8` instead

error: could not compile `playground` due to previous error

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a9dd571a958a5ed35050ab3dff5d0454

[rmlarsen]

I ran into this as well, in the context of constructing arrays. The following buggy value is not detected:

const CATCH_ME = s4[2] : [15,16];