Tune default options, esp. -guard_pages, for large-page machines, esp. AArch64

On an AArch64 machine with 64K pages, the default guard pages around each heap, cache, and stack unit end up occupying a huge portion of the vmm, since many units are 64K or not much larger, making the guard space 2x as much as the used space. For vmheap, with #4418 (closed), we now have 8G by default and maybe extra address space doesn't matter much since we can now arbitrarily increase the size, and every machine should have overcommit where untouched pages are (nearly) free. But for vmcode, we have a 2G hard limit, and there this extra space can be problematic.

This option covers:

• Considering changing the meaning of -guard_pages to not mean around every unit, but in between some units, where we place them in between every Nth vmm alloc. A tradeoff between the security/debugging benefit of guard pages and the space occupied. Note that this may also be necessary for #4415 if the vmm starts handing out sub-page units, where it cannot then put guard pages around them but only around every N of them.
• Tuning the various heap and cache unit size parameters for large page sizes. Today adjust_defaults_for_page_size() tries to do some of this but does not touch the cache sizes and should be re-evaluated.

For per-thread data structures, large-page wastage can really add up. E.g., the stack, signal stack, heap, and sigpending allocs are often <64K (much less for heap and sigpending), yet today they can end up occupying 196K each, leading to a huge amount of sparsely used address space for an app with thousands of threads. That's where we may want #4415.