Summary

Replace the cnkChckRange node kinds with a magic call that is already
inserted during MIR synthesis (mirgen) and remove all decision making
regarding range-checks from the code generators.

This is a step towards moving decision making regarding run-time checks
fully into late semantic analysis. In addition, this fixes destructors
not being run for scopes where the only escaping unstructured control-
flow is due to range checks.

Details

A new internal magic is added for representing conversions-with-range-
checks during the MIR and code generation phase: mChckRange. mirgen
translates nkChckRange, nkChckRange64, and nkChckRangeF to the
new magic, but only if its not a to-unsigned conversion and range checks
are enabled for the current owner.

For now, these guards mirror those previously used in the code
generators, but the direction is to move to a correct-by-construction
approach and only inject nkChckRange nodes where range checks should
be performed.

The mChckRange magic is included in the magicsThatCanRaise set, and
the duplicate set of the same name is removed from mirexec. As a
consequence, the exceptional control-flow arising from failed range
checks is now picked up on by MIR-based data- and control-flow analysis.
However, since the set is constant, this also means that range-check
calls will be treated as raising even when panics are enabled. This is a
known problem with magics that needs to be solved at one point.

Multiple things are now obsolete and thus removed:

• the cnkChckRange node kinds
• the cgirgen logic for producing cnkChckRange nodes (which was
  originally duplicated from the logic in transf.transformConv)
• the code generator handling for cnkChckRange. Parts of it are
  re-used for implementing mChckRange support

Two additional problems are fixed as a side-effect of the changes:

• the VM code generator now respects the rangeChecks option in
  the same way as the other code generator
• disabled range checks (either via the rangeChecks option or
  because the target type is unsigned) are not treated as no-op
  by the JS code generator, but instead use unchecked conversions
  (the tdollars.nim test is adjusted accordingly), in line with
  the other code generators