i#241,i#1693: add kernel transfer client events

[derekbruening]

Adds a new client API event type: a kernel-mediated control transfer. This
includes UNIX signal delivery and return, Windows APCs, callbacks,
exceptions, NtContinue, NtSetContextThread, and callback returns. It is
also raised on client redirects.

The new interface passes the source context (control and integer, no
multimedia) but passes just key target fields directly (new pc, new xsp)
and does not pass in the full target register state to avoid copying costs
(particulary for multimedia). Adds a new internal os_cxt_ptr_t type to
support pointing at a CONTEXT or sig_full_cxt_t for the new events and only
copying from that state if the client calls dr_get_mcontext(). Adds extra
logic to get the source context for dr_redirect_execution() called from the
exception event.

Includes limited support for calling dr_set_mcontext() and changing the pc
or other state, though there seem to be few use cases of this and given the
difficulty in testing it, it's not clear it's a worthwhile feature.

Adds documentation on the disparity between xbp being in CONTEXT_CONTROL
yet in DR_MC_INTEGER, cautioning clients to use both INTEGER and CONTROL
when they care about xbp.

Includes logic to pass the real Ki pc and not the hook-displaced pc for
dispatchers.

I don't think it's possible to pass the real xsi and not the syscall return
address for a cbret: we live with that.

Adds corresponding routines drmgr_register_kernel_xfer_event() and
drmgr_register_kernel_xfer_event_ex(). Re-implements drmgr's CLS API using
the new kernel xfer event (this is required for proper ordering of CLS vs
other clients using the xfer event). Removes
DRMGR_PRIORITY_INSERT_CLS_ENTRY, DRMGR_PRIORITY_INSERT_CLS_EXIT,
DRMGR_PRIORITY_NAME_CLS_ENTRY, and DRMGR_PRIORITY_NAME_CLS_EXIT.

Adds tests to client.signal, client.flush, client.events,
client.drmgr-test, and a new test client.winxfer. Testing of
dr_set_mcontext() on Windows was done manually: automated testing is
challenging to set up and left for future work.

Fixes #241
Fixes #1693

[derekbruening]

The Mac failures seem to be from the Travis OSX upgrades: filed as #2720.