1) when generating short builtin calls/jumps assemblers should use the
   offset from the CodeRange base rather than the start of the code
   range reservation because otherwise it's not guaranteed that the
   PC-relative offset will fit into architecture's constraints.
   The code range reservation start could be different from the code
   range base in the following cases:
     * when the "base bias size" is non-zero (on Windows 64),
     * when we ended up over-reserving the address space for the code
       range, which happens as a last resort to fulfil the CodeRange
       alignment requirements.
   See the VirtualMemoryCage description for details.

Drive-by fixes:
2) in case of over-reserving address space for external code range,
   the pre-calculated hint for where the remapped embedded builtins
   should be copied to was outside of the allocatable CodeRange region
   and thus useless. The fix is to use the allocatable region instead
   of the reservation region when calculating the hint.
3) when allocating CodeRange with zero base bias size we can create
   the VirtualMemory reservation from the first attempt simply by
   passing the required base alignment to the VirtualMemory
   constructor.

Bug: v8:11880, chromium:1290591
Change-Id: If341418947e2170d967e22b38bcc371594939c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78772}