gdb: avoid creating misplaced symtabs for dwz files

This commit fixes the issue that is described in detail in the
previous commit; when processing a DWZ file, GDB can end up creating a
symtab associated with a compunit_symtab for a file that was never
compiled into a given compunit_symtab.

The previous commit added a test for this issue, however, things are
slightly complicated because a recent change to GDB:

  commit a736ff7d886dbcc85026264c3ce11c125a8409b2
  Date:   Sat Sep 27 22:29:24 2025 -0600

      Clean up iterate_over_symtabs

Changed GDB in such a way that the problem being discussed here
no longer appears to cause any incorrect behaviour.  Still, I think
this problem is worth fixing.  Adding additional symtabs that are in
the wrong place has the potential to cause problems in the future, but
also, wastes GDB memory, and increases time needed to search through
all symtabs.

The precise problem here is triggered when a DWZ file is created from
multiple object files (as is usually the case).  The DWZ file will
contain a line table which can hold references to any of the source
files, from any of the object files.  Note that a source file doesn't
have to be included in every object file in order to be added to the
line table of the DWZ file.

Within GDB the problem originates from the 'new_symbol' function (in
dwarf2/read.c).  This function looks for the DW_AT_call_file or
DW_AT_decl_file of a symbol, uses this to lookup the line table entry,
and uses this to obtain the symtab to which the symbol should be
attached.

For an inlined subroutine instance, this information can be split
between an objfile's debug information and a shared DWZ file.  For
example, from the gdb.debuginfod/solib-with-dwz.exp test case, this
first bit of DWARF is from the objfile's debug information:

 <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine)
    <92>   DW_AT_abstract_origin: <alt 0x1b>
    <96>   DW_AT_low_pc      : 0x1121
    <9e>   DW_AT_high_pc     : 31
    <9f>   DW_AT_call_file   : 1
    <a0>   DW_AT_call_line   : 26
    <a1>   DW_AT_call_column : 15
 <3><a2>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <a3>   DW_AT_abstract_origin: <alt 0x2c>
    <a7>   DW_AT_location    : 2 byte block: 91 68      (DW_OP_fbreg: -24)
 <3><aa>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <ab>   DW_AT_abstract_origin: <alt 0x25>
    <af>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)

The DW_AT_abstract_origin attributes are referencing the following
DWARF which has been placed into the DWZ file:

 <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram)
    <1c>   DW_AT_name        : (indirect string, offset: 0x18a): add_some_int
    <20>   DW_AT_decl_file   : 1
    <21>   DW_AT_decl_line   : 24
    <22>   DW_AT_decl_column : 1
    <23>   DW_AT_prototyped  : 1
    <23>   DW_AT_type        : <0x14>
    <24>   DW_AT_inline      : 3        (declared as inline and inlined)
 <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <26>   DW_AT_name        : a
    <28>   DW_AT_decl_file   : 1
    <29>   DW_AT_decl_line   : 24
    <2a>   DW_AT_decl_column : 19
    <2b>   DW_AT_type        : <0x14>
 <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <2d>   DW_AT_name        : b
    <2f>   DW_AT_decl_file   : 1
    <30>   DW_AT_decl_line   : 24
    <31>   DW_AT_decl_column : 26
    <32>   DW_AT_type        : <0x14>

When GDB tries to create the symbols for the DW_TAG_formal_parameter
then this will find the DW_AT_decl_line in the DWZ file.  This will
cause the line table of the DWZ file to be parsed.  This parsing
currently creates symtabs for every file mentioned in the DWZ file's
line table, which includes files that are not part of the original
objfile.

Currently GDB creates and stores the symtabs within the file_entry
object (see dwarf2/line-header.h).  I propose that we make the symtab
creation lazy; when the symtab is requested from a file_entry object,
the symtab will be created at this point.

Doing this will cause another problem though.  In dwarf_decode_lines,
we specifically create all of the symtabs so that there will be a
symtab even for files that contain no code.  We don't want to regress
this case.

The solution is that dwarf_decode_lines will still trigger the symtab
creation (by asking the file_entries for their symtab), unless we're
processing a DWZ file.

We don't need to worry about files that have no code, which are
mentioned in a DWZ file, as these files will also be mentioned in the
original objfile's line table.  When that line table is processed (as
it will be), then symtabs for all files mentioned will be created.  In
this way we will get:

 (a) symtabs for every source file mentioned in the original objfile,
     and

 (b) symtabs for every source file that is specifically used by the
     DWARF from the DWZ file.

I've update the gdb.debuginfod/solib-with-dwz.exp test to check the
symtab creation, and also added gdb.base/dwz-symtabs.exp, which is
very similar to solib-with-dwz.exp, but doesn't depend on debuginfod
and instead just focuses on which symtabs are created, this make the
test a little simpler overall.

Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Simon Marchi <simark@simark.ca>