pc equality complicated by LSB=1 vs LSB=0 Thumb addresses

Xref the original discussions over whether to store fragment tags
internally with LSB=1 to indicate Thumb, and how our own gencode entry
points originally had LSB=1 but we abandoned that. Xref #1688.

This issue covers problems with clients. The immediate issue is that
drwrap app address targets do not match fragment addresses, and there is no
simple solution. Often the passed-in app pc to replace or wrap has LSB=1
(b/c it came from dr_get_proc_address()), yet DR fragment and instr app
pc's have LSB=0.

We can't easily have drwrap clear LSB up front for all passed-in addresses,
b/c the caller might (and does, for the drwrap test) do things like "if
(drwrap_get_func(wrapcxt) == the_func_I_passed_in)".

So where should we clear? Or should DR set LSB=1 in instr_get_app_pc() and
dr_fragment_app_pc()? (Not in dr_app_pc_for_decoding() of course.)
Maybe that makes sense: since function pointers in source code, and
dr_get_proc_address(), will all have LSB=1.

Problem: dr_fragment_app_pc() and dr_app_pc_for_decoding() do not take in
enough info to figure out the ISA mode. We could break back compat and add an
arg, or add an _ex() version, or pay the cost of calling fragment_lookup().

For instr_get_app_pc(): should we store as LSB=1, or only add LSB=1 when
queried? Will we mess up DR's own internal calls to this routine? What if
the client set the xl8 field for that instr? Which then raises questions
about state xl8 and signal events: what about PC fields there?

Start by reading the drwrap address-handling APIs and the entry points named in the issue: dr_get_proc_address(), drwrap_get_func(), dr_fragment_app_pc(), dr_app_pc_for_decoding(), and instr_get_app_pc(). Trace how Thumb LSB values move between client addresses, fragments, instructions, xl8 state, and signal events. Done means choosing and documenting a consistent compatibility-safe representation and resolving the questions raised for each API.

Written by the indexing model from the issue text.