data races reported when using DR for decoding without explicit dr_standalone_init

[derekbruening]

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.

[derekbruening]

These errors are reported on the invariant_checker drmemtrace tool. Having it explicitly call dr_standalone_init() eliminates the errors so we could put that in as a workaround.