add API routine to create a basic block without executing it

[derekbruening]

There are some use cases that involve creating a basic block but not executing it. This has some potential issues with DR assumptions on execution (current isa mode, mcontext state at top of bb, trace building, lazy linking) but I do not think there are any roadblocks.

[derekbruening]

Xref #2463 where we've added a related interface but it's targeted more toward the start/stop API.

[derekbruening]

I'm going to quote from #2463 on the mcontext concern:

The caveat about the mcontext at the top of the bb also applies: the example there is Dr. Memory which uses the mcontext of the very first bb event to get the mcontext for the primary thread to work around DR's failure to provide it there (#1152).

[derekbruening]

Re: the ISA mode: we should add code to set the mode based on the LSB of the bit in the bb tag, as I believe today the decoder/disassembler will switch modes based on LSB but only temporarily and I'm not sure it will be enough for the rest of bb building where we assume the whole block is one mode and may not check every instr's mode?? Needs investigation: maybe it does work.

[derekbruening]

Quoting from dup issue #2561:

Looks like an existing code can work in such a setup with a small trick:

void *drcontext = dr_get_current_drcontext();
dr_prepopulate_cache(tags, count);
dr_switch_to_dr_state_ex(drcontext, DR_STATE_GO_NATIVE);

because after the dr_prepopulate_cache the context is unconditionally switched to the application.

It's sounding like we can extend #2463's pre-population-before-start to mid-execution with just the state shift change here, along with documenting some of the caveats listed above (mcontext-at-top-of-bb assumptions in some clients), and with checking and ensuring the ISA mode does the right thing.

Re: the lazy linking concerns listed up front: I don't think they're anything that will cause trouble.