gdb/dwarf2: skip unrecognised extended opcodes in line-number programs

gdb/dwarf2: skip unrecognised extended opcodes in line-number programs

Although the DWARF 5 specification does not outright state that
consumers should ignore unrecognised opcodes, it does make sure that
this is possible (by always encoding the length of operands), and in
fact states the following:

> The DWARF format is organized so that a consumer can skip over data
> which it does not recognize. This may allow a consumer to read and
> process files generated according to a later version of this standard
> or which contain vendor extensions, albeit possibly in a degraded
> manner.

In addition, it is mentioned in the body of DWARF Issue 180426.2 that
producers can, today, include padding bytes in line number programs by
emitting an unused extended opcode:

> In a related thread on dwarf-discuss, Cary pointed out that given how
> DWARF works, any undefined extended opcode could be used for this
> purpose. [...] consumers already know how to skip an unrecognized
> extended opcode.

Previously, if GDB encountered an unknown extended opcode in a DWARF
line number program, it would stop evaluating the program with an error.
This commit causes it to instead skip the extended opcode, leaving the
virtual machine state unmodified. As well as being supported by the
quotes above, this is consistent with GDB's *existing* handling of the
case where a *standard* LNP opcode is unrecognised.

The motivation for this change is binaries emitted by the Zig compiler,
which currently uses extended opcode 0 for padding bytes (the use case
being addressed in DWARF 6 by the DWARF issue referenced above). LLDB is
capable of parsing these line number programs, but GDB was not prior to
this commit.

Tested by running the test suite (including the added test case) and
confirming that every test which previously passed continues to pass.
Also manually tested on a binary produced by the Zig compiler, where
previously GDB was missing some line number information, but now has
complete and correct information.

Approved-By: Tom Tromey <tom@tromey.com>