[vm] inefficiencies found while building simdjson in SWAR. #64477

When SIMD is not available, some benefits of SIMD are available via SIMD-within-a-register (SWAR) techniques, that is, by using operations over 64-bit wide integers.

I ran an experiment that tried to implement simdjson in SWAR and I found a couple of inefficiencies that I plan to fix:

• a | ~b, a ^ ~b, a & ~b has no peephole optimizations for arm64 where single instruction operations exist. (Also, we might want to not ship Int32x4.andNot and have a peephole instead SIMD tracking issue. #64170)
• toDouble is slow AOT: int.toDouble() in a hot loop is 5x slower than the same conversion written as 0.0 + x #64209.
• bitLength is slow so a clz via bitLength is slow too.
• The unsafe bounds check elimination pragma does not work transitively across inlined methods. There are simple cases where BCE isn't able to eliminate bounds checks, in particular: ByteData accessors bounds check every access twice #64236 we should improve BCE on AOT.
• Range analysis doesn't propagate ranges for min/max.
• String.fromCharCodes doesn't have any fast-paths for creating TwoByteStrings more efficiently from Uint16Lists.
• <integer> & 0xFFFFFFFF appears to switch to 32-bit operations on 64-bit systems which adds unnecessary conversion operations.
• utf8 decoding has a bug where it removes BOM inside of a buffer not just at the start.
• records unbox at most 2-ary record return values (https://dart-review.googlesource.com/c/sdk/+/269100 & [vm] Records of primitives requires boxing #51637), I think we should support unboxing more.