[gdb/exp] Fix ignoring of incorrect namespace prefix

Consider test.c, compiled to a.out using "g++ -g test.c":
...
     1  namespace mod_a { int xxx = 10; }
     2  namespace mod_b { using namespace mod_a;
     3                    int yyy = 20; }
     4  int main (void) {
     5    using namespace mod_b;
     6    void (xxx + yyy);
     7    return 0;
     8  }
...

When trying to print the value of non-existent variable mod_a::yyy, we get:
...
$ gdb -q -batch a.out -ex start -ex "print mod_a::yyy"
  ...
Temporary breakpoint 1, main () at test.c:7
7         return 0;
$1 = 20
...

The problem is in cp_lookup_symbol_via_imports, where we decide that the
"using namespace mod_b" from main is applicable in scope mod_a.

More concretely, cp_lookup_symbol_via_imports is called with:
- scope == "mod_a",
- name == "yyy", and
- block.m_function.m_name == "main()",
and when looking at "using namespace mod_b":
...
(gdb) p *current
$12 = {import_src = 0x344018c "mod_b", import_dest = 0x1b477a0 "",
       alias = 0x0, declaration = 0x0, next = 0x0, decl_line = 5,
       searched = 0, excludes = {0x0}}
...
we hit "directive_match = true" because strlen (current->import_dest) == 0.

Fix this by being more strict in the calculation of directive_match:
...
          if (len == 0)
-           directive_match = true;
+           {
+             const char *current_scope = (block->function_block () != nullptr
+                                          ? block->scope ()
+                                          : nullptr /* Don't know.  */);
+             directive_match = (current_scope != nullptr
+                                ? streq (scope, current_scope)
+                                : true /* Assume there's a match.  */);
+           }
...
which gets us:
- current_scope == "", and
- directive_match == false,
because scope == "mod_a", so streq (scope, current_scope) == false.

As is clear from the code, in case we don't know the current scope, we assume
there's a match.  This may be harmless, or this may describe a cornercase we
haven't run into yet.  If so, it's a pre-existing issue.

The new test-case contains regression tests for:
- PR34051, and
- PR34034 for which it contains a kfail.

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