[gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p

[gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p

When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names, I run into:
...
(gdb) print base::operator new^M
^M
^M
Fatal signal: Segmentation fault^M
----- Backtrace -----^M
0x57ea46 gdb_internal_backtrace_1^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M
0x57eae9 _Z22gdb_internal_backtracev^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M
0x75b8ad handle_fatal_signal^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M
0x75ba19 handle_sigsegv^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M
0x7f795f46a8bf ???^M
0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M
        /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M
...

The problem is in this piece of code in dw2_debug_names_iterator::next:
...
        case DW_IDX_type_unit:
          /* Don't crash on bad data.  */
          if (ull >= per_bfd->tu_stats.nr_tus)
            {
              complaint (_(".debug_names entry has bad TU index %s"
                           " [in module %s]"),
                         pulongest (ull),
                         objfile_name (objfile));
              continue;
            }
          per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus);
          break;
...

The all_comp_units vector (which get_cu accesses) contains both CUs and TUs,
with CUs first.

So to get the nth TU we need the element at "nr_cus + n", but
the code uses "nr_tus + n" instead.

Fix this by using "nr_cus + n".

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29334