gdb/python: make more use of RegisterDescriptors

This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.

Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number.  I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind.  However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.

Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.

This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.

The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly.  However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.

As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.

After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.

gdb/ChangeLog:

	* python/py-frame.c: Remove 'user-regs.h' include.
	(frapy_read_register): Rewrite to make use of
	gdbpy_parse_register_id.
	* python/py-registers.c (gdbpy_parse_register_id): New function,
	moved here from python/py-unwind.c.  Updated the return type, and
	also accepts register descriptor objects.
	* python/py-unwind.c: Remove 'user-regs.h' include.
	(pyuw_parse_register_id): Moved to python/py-registers.c.
	(unwind_infopy_add_saved_register): Update to use
	gdbpy_parse_register_id.
	(pending_framepy_read_register): Likewise.
	* python/python-internal.h (gdbpy_parse_register_id): Declare.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind.py: Update to make use of a register
	descriptor.

gdb/doc/ChangeLog:

	* python.texi (Unwinding Frames in Python): Update descriptions
	for PendingFrame.read_register and
	gdb.UnwindInfo.add_saved_register.
	(Frames In Python): Update description of Frame.read_register.

gdb/doc/python.texi

@@ -2458,12 +2458,11 @@ provides a method to read frame's registers:
 
 @defun PendingFrame.read_register (reg)
 This method returns the contents of the register @var{reg} in the
-frame as a @code{gdb.Value} object.  @var{reg} can be either a
-register number or a register name; the values are platform-specific.
-They are usually found in the corresponding
-@file{@var{platform}-tdep.h} file in the @value{GDBN} source tree.  If
-@var{reg} does not name a register for the current architecture, this
-method will throw an exception.
+frame as a @code{gdb.Value} object.  For a description of the
+acceptable values of @var{reg} see
+@ref{gdbpy_frame_read_register,,Frame.read_register}.  If @var{reg}
+does not name a register for the current architecture, this method
+will throw an exception.
 
 Note that this method will always return a @code{gdb.Value} for a
 valid register name.  This does not mean that the value will be valid.
@@ -2532,8 +2531,8 @@ create a @code{gdb.UnwindInfo} instance.  Use the following method to
 specify caller registers that have been saved in this frame:
 
 @defun gdb.UnwindInfo.add_saved_register (reg, value)
-@var{reg} identifies the register.  It can be a number or a name, just
-as for the @code{PendingFrame.read_register} method above.
+@var{reg} identifies the register, for a description of the acceptable
+values see @ref{gdbpy_frame_read_register,,Frame.read_register}.
 @var{value} is a register value (a @code{gdb.Value} object).
 @end defun
 
@@ -4687,10 +4686,29 @@ Return the frame's symtab and line object.
 
 @anchor{gdbpy_frame_read_register}
 @defun Frame.read_register (register)
-Return the value of @var{register} in this frame.  The @var{register}
-argument must be a string (e.g., @code{'sp'} or @code{'rax'}).
-Returns a @code{Gdb.Value} object.  Throws an exception if @var{register}
-does not exist.
+Return the value of @var{register} in this frame.  Returns a
+@code{Gdb.Value} object.  Throws an exception if @var{register} does
+not exist.  The @var{register} argument must be one of the following:
+@enumerate
+@item
+A string that is the name of a valid register (e.g., @code{'sp'} or
+@code{'rax'}).
+@item
+A @code{gdb.RegisterDescriptor} object (@pxref{Registers In Python}).
+@item
+A @value{GDBN} internal, platform specific number.  Using these
+numbers is supported for historic reasons, but is not recommended as
+future changes to @value{GDBN} could change the mapping between
+numbers and the registers they represent, breaking any Python code
+that uses the platform-specific numbers.  The numbers are usually
+found in the corresponding @file{@var{platform}-tdep.h} file in the
+@value{GDBN} source tree.
+@end enumerate
+Using a string to access registers will be slightly slower than the
+other two methods as @value{GDBN} must look up the mapping between
+name and internal register number.  If performance is critical
+consider looking up and caching a @code{gdb.RegisterDescriptor}
+object.
 @end defun
 
 @defun Frame.read_var (variable @r{[}, block@r{]})