YJIT: Use the system page size when the code page size is too small
	 (#7267)

	Previously on ARM64 Linux systems that use 64 KiB pages
	(`CONFIG_ARM64_64K_PAGES=y`), YJIT was panicking on boot due to a failed
	assertion.

	The assertion was making sure that code GC can free the last code page
	that YJIT manages without freeing unrelated memory. YJIT prefers picking
	16 KiB as the granularity at which to free code memory, but when the
	system can only free at 64 KiB granularity, that is not possible.

	The fix is to use the system page size as the code page size when the
	system page size is 64 KiB. Continue to use 16 KiB as the code page size
	on common systems that use 16/4 KiB pages.

	Add asserts to code_gc() and free_page() about code GC's assumptions.

	Fixes [Bug #19400]
	---
	 yjit/src/asm/mod.rs    | 78 ++++++++++++++++++++++++++++++++------------------
	 yjit/src/codegen.rs    |  2 --
	 yjit/src/virtualmem.rs | 13 +++++++++
	 3 files changed, 63 insertions(+), 30 deletions(-)

	YJIT: Fix assertion for partially mapped last pages (#7337)

	Follows up [Bug #19400]
	---
	 test/ruby/test_yjit.rb | 19 +++++++++++++++++++
	 yjit/src/asm/mod.rs    |  2 +-
	 yjit/src/virtualmem.rs | 18 +++++++++++++-----
	 3 files changed, 33 insertions(+), 6 deletions(-)

YJIT: Skip padding jumps to side exits

Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>

Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>

when it fails to allocate a new page.

Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>

On ARM64, all zeros is already undefined, so we don't need to do extra
work to fill new memory with undefined instructions.

This commit makes YJIT allocate memory for generated code gradually as
needed. Previously, YJIT allocates all the memory it needs on boot in
one go, leading to higher than necessary resident set size (RSS) and
time spent on boot initializing the memory with a large memset().

Users should no longer need to search for a magic number to pass to
`--yjit-exec-mem` since physical memory consumption should now more
accurately reflect the requirement of the workload.

YJIT now reserves a range of addresses on boot. This region start out
with no access permission at all so buggy attempts to jump to the region
crashes like before this change. To get this hardening at finer
granularity than the page size, we fill each page with trapping
instructions when we first allocate physical memory for the page.

Most of the time applications don't need 256 MiB of executable code, so
allocating on-demand ends up doing less total work than before. Case in
point, a simple `ruby --yjit-call-threshold=1 -eitself` takes about
half as long after this change. In terms of memory consumption, here is
a table to give a rough summary of the impact:

    | Peak RSS in MiB | -eitself example | railsbench once |
    | :-------------: | ---------------: | --------------: |
    |     before      |              265 |             377 |
    |      after      |               11 |             143 |
    |     no YJIT     |               10 |             101 |

A new module is introduced to handle allocation bookkeeping.
`CodePtr` is moved into the module since it has a close relationship
with the new `VirtualMemory` struct. This new interface has a slightly
smaller surface than before in that marking a region as writable is no
longer a public operation.