RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators

[Aleksey Shipilev]

The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else.

We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. 

This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers.

`hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
 - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
 - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation

-------------

Commit messages:
 - More polish
 - RISC-V version
 - More touchups, AArch64 version
 - Store barrier cleanup

Changes: https://git.openjdk.org/jdk/pull/29444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376472
  Stats: 269 lines in 10 files changed: 47 ins; 61 del; 161 mod
  Patch: https://git.openjdk.org/jdk/pull/29444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29444/head:pull/29444

PR: https://git.openjdk.org/jdk/pull/29444