vmgen: fix two overflow bugs with sets

[zerbina]

Summary

Fix either the compiler crashing or the VM failing at run-time with an
over- or underflow defect for incl, contains, and construction
operations for sets where the element range crossed the int64 upper
boundary.

The fixed bugs only affected VM bytecode generation and code running in
the VM.

Details

There were two related problems:

• the relevant vmgen logic performed all math with signed integer
  values
• preparing (i.e., offsetting) a run-time value for a set operation
  always happened via SubInt (subtract signed integer), ignoring
  the signed-ness of the operands

When the lower bound of the elements' range was beyond the int64 upper
bound, this didn't cause problems: reinterpreting the integer bits
always yields negative values there. For example, for a set[Low..High]
where Low == high(uint64)-3 and High = high(uint), subtracting the
lower inclusive-bound (-4) from the upper inclusive-bound (-1) both
didn't cause and overflow and also resulted in the correct value (3).

However, when Low == uint64 high(int64) and High == Low + 4, this
doesn't work. When the operand to an operation involving such sets was a
literal integer outside the int64 range, the compiler crashed - when
it was a run-time value, the VM erroneously reported an overflow.

The logic for generating the code for loading set elements now uses
Int128 to get around over- and underflow problems, and the Subu
operation is emitted for offsetting unsigned run-time values.

In addition, generating the bytecode for loading literal unsigned
integers now happens via loadInt, meaning that the values are now
loaded via LdImmInt if they're less than 2^23. Previously, literal
unsigned integers were always loaded via the slightly less efficient
LdConst operation.

[saem]

Nice fix. That reminds me I should re-test release builds of the compiler to see if they're clean.

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• I re-discovered the issue while experimenting with storing the value for unsigned integer literals as BiggestUInt