RFR: 8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores

[Aleksey Shipilev]

There is a regression introduced by addition of ARMv7-specific block by JDK-8211387. It readily manifests as crash
during jcstress initialization, and investigation points at broken volatile stores. Reverting JDK-8211387 from head JDK
makes ARM32 start and run jcstress.

The underlying reason seems to be the half-done `atomic_copy64`: it does the load with exclusive load, but then defers
to the C++ store. Somewhere during handing over the value from the asm load to C++ store and/or C++ store itself, we
garble the value. The way out is to implement the whole thing in asm.

Also see `StubGenerator::generate_atomic_load_long` and `StubGenerator::generate_atomic_store_long` in
`stubGenerator_arm.cpp`, that do roughly the same thing and were the basis for this implementation.

Attention @theRealAph, @bulasevich.

Testing:
 - [ ] ARM32 Linux zero release jcstress run

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

Commit messages:
 - Whitespace fixes
 - Typo tmp_r -> tmp_w
 - 8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores

Changes: https://git.openjdk.java.net/jdk/pull/299/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=299&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253464
  Stats: 17 lines in 1 file changed: 8 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/299.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/299/head:pull/299

PR: https://git.openjdk.java.net/jdk/pull/299