data races reported when using DR for decoding without explicit dr_standalone_init

As part of #2499 we try to support using drdecodelib, or libdynamorio.so's decode routines, without an explicit initialization call such as dr_standalone_init. However, the lazy init's gating checks and initialization ends up flagged by race detectors such as ThreadSanitizer. Some of these complaints, such as about the `standalone_library` variable itself, are less concerning on x86 where acquire-release semantics are the default; but on arm they do point out real potential issues.

Here are the complaints:

In the triggers for auto-calling standalone_init:
+ standalone_library (should be changed to use explicit acquire-release)
+ heapmgt->global_heap_writable (should be replaced by dynamo_heap_initialized using acquire-release)
+ heapmgt (ditto)

Things initialized:
+ initexit_isa_mode (for this one the initializer is now static so we can remove the code writing it in d_r_decode_init)
+ cpu_info: proc_init() vs proc_get_vendor() during decoding

For moving to acquire-release: we have ATOMIC_1BYTE_WRITE and atomic_read_bool. The write on x86 is overkill for release, using xchg: but that ends up being a benefit as it satisfies ThreadSanitizer.

Xref #2502 on other lockless issues on arm.

Xref #1409 on refactoring DR code: we can probably remove some of the initialization for standalone mode. It would be nice to remove DR heap initialization: but we can't easily invoke malloc for non-STATIC_LIBRARY.