The assertion logic is the only thing actually changing within
`lj_ir_kptr_`: the existing `mref` / `setmref` invocations already deal in
zero-extended pointers rather than sign-extended pointers.
Perhaps surprisingly, the logic around continuation pointers is changing.
To appreciate why, the following cryptic comment from vm_x86.dasc comes
into play:
```
|->cont_dispatch:
...
| movsxd RAa, dword [RB-16] // May be negative on WIN64 with debug.
```
Namely, when using MSVC in debug mode, function symbols with external
linkage are subject to extra jump stubs in order to support incremental
linking. For example, these jump stubs might look like:
```
...
lj_bcwrite:
07FFC47A5EF23 jmp lj_bcwrite (07FFC47AB5750h)
lj_cont_ra:
07FFC47A5EF28 jmp lj_cont_ra (07FFC47A6230Dh)
lj_ir_call:
07FFC47A5EF2D jmp lj_ir_call (07FFC47AF6310h)
lj_cconv_tv_bf:
07FFC47A5EF32 jmp lj_cconv_tv_bf (07FFC47AC1EA0h)
...
```
When continutation pointers are formed, it is e.g. 07FFC47A5EF28 rather
than 07FFC47A6230 from which lj_vm_asm_begin gets subtracted, and it can
be the case that 07FFC47A5EF28 is less than lj_vm_asm_begin. Consequently,
this could previously result in continuation pointers in range [-2G, 0).
(The eagle-eyed reader might think that lj_vm_asm_begin is also a function
symbol with external linkage, but buildvm is careful to define it as a
data symbol rather than a function symbol).
This change was actually motivated by an assertion failure in WIN64 debug
mode (wherein `snap_replay_const` does `lj_ir_kptr(J, ir_kptr(ir))`, as
`ir_kptr` performs zero-extension, and then `lj_ir_kptr` would barf), but
given the recent block allocator change to support the [0, 4G) address
range on (non-x64) 64-bit platforms, the change seems prudent for other
reasons too.
Use a mix of linear probing and pseudo-random probing.
Workaround for 1GB MAP_32BIT limit on Linux/x64. Now 2GB with !LJ_GC64.
Enforce 128TB LJ_GC64 limit for > 47 bit memory layouts (ARM64).
