Shenandoah: reconsider bitmap access memory ordering

Shenandoah currently uses its own marking bitmap (added by JDK-8254315). It accesses the marking bitmap with "acquire" for reads and "conservative" for updates. Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64.

I think both are actually excessive for marking bitmap accesses: we do not piggyback object updates on it, the atomics there are only to guarantee the access atomicity and CAS updates to bits. It seems "relaxed" is enough for marking bitmap accesses.