Avoid standard heap in droption and drcachesim init

[derekbruening]

While typical shared-library usage of DR isolates a client's heap from the app, when DR and clients are statically linked into the application there is unfortunately no way to isolate. We're already using placement new at runtime in drcachesim to support static usage. We'd been assuming that application heap usage at client init time was relatively safe, for internally-triggered attach where the init thread is at a clean ABI point. However, we have hit issues with application heap and tools that replace the allocator with a scheme involving SIGSEGV for detecting bugs. During attach, the init thread then raises SIGSEGV, running into signal delivery problems under #1921. While we plan to solve all the #1921 cases in any case, it may be worth providing app-heap-free options, for possible ptrace-attach with static DR or other cases where worse problems arise, or cases where clients need to parse options post-init-time.

Xref #4640 (comment) where using std::string with a custom allocator that invokes dr_global_alloc for all droption strings does not work with static DR, due to the static initializers that run natively at process init time. An allocator that looks at dynamo_heap_initialized does not work either, as it doesn't know how to free.

A possible solution is to store only literal char* types at init time and only construct std::string at parse time.

Beyond droption, func_trace has a std::vector and std::set which can easily be made to use a custom allocator.

We may want to make a C++ allocator that uses dr_global_heap part of a library exported by DR. Or bundled with droption.