Create script to convert old tests into Dwarf::assemble calls.

Create script to convert old tests into Dwarf::assemble calls.

PR testsuite/32261 requests a script that could convert old .S-based
tests (that were made before dwarf.exp existed) into the new
Dwarf::assemble calls in Tcl. This commit is an initial implementation
of such a script. Python was chosen for convenience, and only relies on
a single external library.

Usage: the script operates not on .S files, but on ELF files with DWARF
information. To convert an old test, one must run said test via
`make check-gdb TESTS=testname` in their build directory. This will
produce, as a side effect, an ELF file the test used as an inferior, at
gdb/testsuite/outputs/testname/testname. This ELF file is this script's
input.

Reliability: not counting the limitations listed below, the script seems
functional enough to be worthy of discussion in the mailing list. I have
been testing it with different tests that already use Dwarf::assemble,
to see if the script can produce a similar call to it. Indeed, in most
cases that I've tested (including some more complex ones, marked with an
asterisk below) it is able to produce comparable output to the original
exp file. Of course, it can't reproduce the complex code *before* the
Dwarf::assemble call. Values calculated then are simply inlined.

The following .exp files have been tried in this way and their outputs
highly resemble the original:
- gdb.dwarf2/dynarr-ptr
- gdb.dwarf2/void-type
- gdb.dwarf2/ada-thick-pointer
- gdb.dwarf2/atomic-type
- gdb.dwarf2/dw2-entry-points (*)
- gdb.dwarf2/main-subprogram

The following .exp files work, with caveats addressed in the limitations
section below.
- gdb.dwarf2/cpp-linkage-name
  - Works correctly except for one attribute of the form SPECIAL_expr.
- gdb.dwarf2/dw2-unusual-field-names
  - Same as above, with two instances of SPECIAL_expr.
- gdb.dwarf2/implptr-optimized-out
  - Same as above, with two instances of SPECIAL_expr.
- gdb.dwarf2/negative-data-member-location
  - Same as above, with one instance of SPECIAL_expr.

The following .exp files FAIL, but that is expected:
- gdb.dwarf2/staticvirtual.exp
  - high_pc and low_pc of subprogram "~S" are hardcoded in the original
    .exp file, but they get replaced with a get_func_info call. Since
    the function S::~S is not present in the original, get_func_info
    will fail.

The following .exp files DO NOT WORK with this script:
- gdb.dwarf2/cu-no-addrs
  - `aranges` not supported.
  - Compile unit high_pc and low_pc hardcoded, prone to user error
    due to forgetting to replace with variables.
- gdb.dwarf2/dw2-inline-stepping
  - Same as above.
- gdb.dwarf2/fission-relative-dwo
  - `fission` not supported.
- gdb.dwarf2/dw2-prologue-end and gdb.dwarf2/dw2-prologue-end-2
  - Line tables not supported.

Currently the script has the following known limitations:
- It does not support line tables.
- It does not use $srcfile and other variables in the call to
  Dwarf::assemble (since it can't know where it is safe to substitute).
- It does not support "fission" type DWARFs (in fact I still have no
  clue what those are).
- It does not support cu {label LABEL} {} CUs, mostly because I couldn't
  find the information using pyelftools.
- It sometimes outputs empty CUs at the start and end of the call. This
  might be a problem with my machine, but I've checked with DWARF dumps
  and they are indeed in the input ELF files generated by
  `make check-gdb`.
- It does not support attributes with the forms DW_FORM_block* and
  DW_FORM_exprloc. This is mostly not a concern of the difficulty of
  the implementation, but of it being an incomplete feature and, thus,
  more susceptible to users forgetting to correct its mistakes or
  unfinished values (please see discussion started by Guinevere at
  comment 23 https://sourceware.org/bugzilla/show_bug.cgi?id=32261#c23).
  The incompleteness of this feature is easy to demonstrate: any call to
  gdb_target_symbol, a common tool used in these attributes, needs a
  symbol name that is erased after compilation. There is no way to guess
  where that address being referenced in a DW_OP_addr comes from, and it
  can't be hard coded since it can change depending on the machine
  compiling it.

Please bring up any further shortcomings this script may have with your
expectations.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32261
Approved-By: Tom Tromey <tom@tromey.com>