MulSaturated and AddSaturated are now implemented for u128, i128
SubSaturated is now implemented for Dec even if it's a little strange to
saturate at a decimal value:
```
» Num.subSaturated -170_141_183_460_469_231_731dec 1
-170141183460469231731.687303715884105728 : Dec
```
I decided to rm the `build_num_{mul,add}_saturated` methods because
they don't require any asm-specifics. They either call out to bitcode, or
use the non-saturated version for floats.
Dec negation was implemented across gen-dev, gen-llvm, gen-wasm as a call
to the compiled zig function `bitcode::DEC_NEGATE`.
f32 and f64 negation were implemented already for gen-llvm, gen-wasm.
for gen-dev x86_64, float negation is implemented by flipping the sign
bit, which means `xorps` for f32, and `xorpd` for f64
for gen-dev aarch64, there is conveniently a `fneg` instruction
This was never fully hooked up in platforms, and the plan is to replace the need for this with doing purity-inference on normal `expect` statements.
On the other hand, fuzzing is finding some bugs caused by having a hyphenated keyword, so this is a great time to go ahead and remove it!
The usize one gets used internally for things like
pattern matches. This is both more efficient (means
they don't have to do unnecessary casts) and also
less error-prone due to e.g. comparing length to
capacity, which is usize.
This is super slow. When trying to compile a "real" app like rocci-bird or the false interpreter,
the compiler will just hang in repeated calls to this function.
I am not sure if this "fix" is valid. I would assume that hashing the names should be equivalent hashing
the InLayout. The InLayout should be a unique id that maps to the layout. The layout should map to name.
So I think it should be a fix.
I haven't done intensive testing, but this is way way faster.
