AArch64: Strengthen CompressedClassPointers initialization check for base

This bugid is trying to address two issues, which should be able to be solved by installing additional checks for the base address of CompressedClassPointers during initialization.

First, using CompressedClassSpaceBaseAddress with an address over 4g and not aligned to 4g will cause a crash on debug build:
$./build/linux-aarch64-server-fastdebug/images/jdk/bin/java -Xshare:off -XX:CompressedClassSpaceBaseAddress=50g -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/yude.lyd/yude.lyd/jdk-master2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4675), pid=36060, tid=36062
# guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment
#
# JRE version: (23.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.yudelyd.jdk-master2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x121b9e0] MacroAssembler::klass_decode_mode()+0x228
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /mnt/yude.lyd/jdk-master2/hs_err_pid36060.log
#
#
Aborted

Secondly, there is this path in Metaspace::reserve_address_space_for_compressed_classes that might lead to similar crashes in release build if we are incredibly unlucky:
```
  NOT_ZERO(result =
      (char*) CompressedKlassPointers::reserve_address_space_for_compressed_classes(size, RandomizeClassSpaceLocation,
                                                                                    optimize_for_zero_base));

  if (result == nullptr) {
    // Fallback: reserve anywhere
    log_debug(metaspace, map)("Trying anywhere...");
    result = os::reserve_memory_aligned(size, Metaspace::reserve_alignment(), false);
  }
```
If the first reserve function fails, the second reserve function comes in, which disregards some important constraints on aarch64 (4g alignment etc.)
(The first reserve function could fail due to aslr. Not that I have observed a failure.)