When lldb gets the register definitions from the response of a

qXfer:features:read:target.xml packet, or via the
plugin.process.gdb-remote.target-definition-file setting, if the
register definition doesn't give us eh_frame or DWARF register
numbers for that register, try to get that information from the ABI
plugin.

The DWARF/eh_frame register numbers are defined in the ABI
standardization documents - so getting this from the ABI plugin is
reasonable.  There's little value in having the remote stub inform
us of this generic information, as long as we can all agree on the
names of the registers.

There's some additional information we could get from the ABI.  For
instance, on ABIs where function arguments are passed in registers,
lldb defines alternate names like "arg1", "arg2", "arg3" for these
registers so they can be referred to that way by the user.  We could
get this from the ABI if the remote stub doesn't provide that.  That
may be something worth doing in the future - but for now, I'm keeping
this a little more minimal.

Thinking about this, what we want/need from the remote stub at a
minimum are:

 1. The names of the register
 2. The number that the stub will use to refer to the register with
    the p/P packets and in the ? response packets (T/S) where 
    expedited register values are provided
 3. The size of the register in bytes
   
(nice to have, to remove any doubt)
 4. The offset of the register in the g/G packet if we're going to
    use that for reading/writing registers.

debugserver traditionally provides a lot more information in
addition to this via the qRegisterInfo packet, and debugserver 
augments its response to the qXfer:features:read:target.xml
query to include this information.  Including:

DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754,
Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*,
float), registers that should be marked as invalid if this 
register is modified, and registers that contain this register.

We might want to get all of this from the ABI - I'm not convinced
that it makes sense for the remote stub to provide any of these 
details, as long as the ABI and remote stub can agree on register
names.

Anyway, start with eh_frame and DWARF coming from the ABI if 
they're not provided by the remote stub.  We can look at doing
more in the future.

<rdar://problem/22566585> 

llvm-svn: 247121