This pr is to address the performance issue gdb has when looking up symbols in STATIC_BLOCK.

gdb will iterate over all CUs looking for static symbols as a last resort, but this introduces performance issues that one might not easily predict.
See pr 16253 for an example of accidentally introducing such a perf regression.

E.g., to perform "info fun ^foo::(anonymous namespace)", inspect_type will first look in STRUCT_DOMAIN for a symbol, and if that fails look in VAR_DOMAIN.  However, the attributes in .gdb_index don't distinguish STRUCT_DOMAIN types from VAR_DOMAIN types.  During symbol lookup, dw2_symtab_iter_next will return every entry that exists for int64 (and there can be thousands), gdb will expand the CU, look for the symbol, not get a match because it's in the wrong domain, and then try the next.
This will cause gdb to expand every CU.  Then when this lookup fails inspect_type will try VAR_DOMAIN, assuming the user was willing to wait that long ...

In this case the "last resort" lookup is killing us, we want the lookup in STRUCT_DOMAIN to fail fast.

ref: symtab.c:lookup_symbol_aux
    /* Now search all static file-level symbols.  Not strictly correct,                                                                                          
       but more useful than an error.  */

  =>return lookup_static_symbol_aux (name, domain);

"more useful than an error" is ignoring the *massive* performance hit (and by massive I mean effectively doing a -readnow in a program with a 2G fission .dwp file).

There is also the issue of looking up base types like "int". It can be slower than necessary too, for similar reasons.  Plus if some type isn't defined in the CU (say double) then we want gdb to look in the default set (provided by the architecture) after it has looked in the current CU and before it does this last
resort attempt of looking through all CUs.  One reason for doing this is that if the next CU to be looked in happened to be compiled with -fshort-double gdb will give the wrong answer.