CRASH static app writing to errno with emulated brk

Xref #1004 (closed) where this exact thing happened with the original brk due to DR's mmaps happening to be placed next to the real break. Here we have seen a similar case but it is with the emulated break.

An early call to brk() fails because a tracing tool library (libdrsyms.so) was loaded by the kernel right next to the emulated break managed by DR.  The brk() code then enters an error path which writes to errno located at an offset from %fs, but this is so early (~220 blocks in) that the %fs segment has not been set up yet (that's at ~260 blocks), so the brk() code crashes.

privload_load_finalize: loaded libdrsyms.so @ 0x00000000009c1000-0x0000000000c0f000 from /.../libdrsyms.so

emulate_app_brk: cur=0x00000000009c0000, requested=0x00000000009c2a00
emulate_app_brk: mremap to 0x00000000009c3000 failed

Many tool libraries have preferred bases set to place them in certain locations, but libdrsyms.so and libdrmemtrace.so did not set custom bases and have the same default preferred, so the 2nd one (libdrsyms) ends up wherever the kernel places it.  

General heap allocation has to handle brk() failing, so this could be viewed as an application bug.  However, this is in some very early bootstrapping code, so probably the authors do not expect failure and never tested this error path.

We could try "-no_emulate_brk" as a workaround, which may or may not work depending again on where some mmaps fall: it might hit #1004 (closed).

For a better solution, should we reserve a big region in our emulated break location as no-access to block other mmaps, and use MAP_FIXED to extend the break?