Subworkspaces causes errors in result of bazel query command

### Description of the problem / feature request:

We have subworkspaces in our project and that causes problems for us with the query command.
We have noticed that bazel does not detects that there is a subworkspace and instead just treat it as
packages belonging to the workspace above.
The problem comes when the target is addressed as @repo1//... and if there is a subrepo @repo2 is is just
treated as packages beloning to repo1.

More detailed description below

### Example 1:

Our test project:

```

Norden/
├── BUILD
├── HelloNorden.cc
├── HelloNorden.hh
├── WORKSPACE
└── World
├── BUILD
├── HelloWorld.cc
├── HelloWorld.hh
├── Universe
│   ├── BUILD
│   ├── HelloUniverse.cc
│   ├── HelloUniverse.hh
│   ├── WORKSPACE
│   └── foo.bzl
└── WORKSPACE

```

```
>more Norden/WORKSPACE
local_repository(
name = "europe",
path = "../Europe",
)

local_repository(
name = "world",
path = "World",
)

>more Norden/BUILD
cc_binary(
name = "HelloNorden",
srcs = ["HelloNorden.cc", "HelloNorden.hh"],
deps = ["@europe//:HelloEurope", "@world//:HelloWorld"],
visibility = ["//visibility:public"],
)

>more Norden/World/WORKSPACE

>more Norden/World/BUILD
cc_library(
name = "HelloWorld",
srcs = ["HelloWorld.cc"],
hdrs = ["HelloWorld.hh"],
visibility = ["//visibility:public"],

)
```
We are running from the the directory bazel:
```
>more WORKSPACE
local_repository(
name = "world",
path = "../../bbi/testarea/tutorialFromBazel/54322/Norden/World",
)

local_repository(
name = "norden",
path = "../../bbi/testarea/tutorialFromBazel/54322/Norden",
)

```
The following commands gives different results:
```

>bazel query 'attr(visibility, "//visibility:public",@norden//...)'
@norden//World:HelloWorld
@norden//:HelloNorden
Loading: 2 packages loaded

>cd cd ../../bbi/testarea/tutorialFromBazel/54322/Norden/
>bazel query 'attr(visibility, "//visibility:public",//...)'
//:HelloNorden
Loading: 1 packages loaded

```
The different targets @norden//... and //... gives different results. //... gives only result from Norden,
@norden//:HelloNorden
while @norden//... gives
@norden//World:HelloWorld
@norden//:HelloNorden

When reading about bazel, we get the impression that both these should give the same result: @norden//:HelloNorden

### Example 2:

In our project we run into an error when running the command in another project:

```
bazel query 'attr(visibility, "//visibility:public", @bbi//...)'

>bazel query 'attr(visibility, "//visibility:public", @bbi//...)'
ERROR: error loading package '@bbi//tools/cda/cda_fludm': cannot load '@bbi//:cda.bzl': no such file
Loading: 11 packages loaded
currently loading: @bbi//tutorials/tutorialUBSan/flex ... (25 packages)
Fetching @svp; fetching ]
Fetching @fader2_sdk; fetching
Fetching @cda_server; fetching

bbi (contains WORKSPACE )
|
- tools
|
- cda (contains WORKSPACE)
|
- cda.bzl
- cda_fludm (BUILD contains that following statement load("//:cda.bzl", "cda_module"))

```

The reason for the error is that bazel does not detect that cda is it own workspace.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Running the command in a workspace containing a subworkspace

### What operating system are you running Bazel on?

Linux

### What's the output of `bazel info release`?

development version

### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.
Cloned the bazel repo and comiled it

### What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

facc7d5273dc31bfca04968f0ee1ed7d2769ddf9
4fd8e562a061dd6b1481ed034f276a6d41d70507

### Have you found anything relevant by searching the web?

No

### Any other information, logs, or outputs that you want to share?

> Replace these lines with your answer.
>
> If the files are large, upload as attachment or provide link.

Start by reproducing the Bazel query commands against the nested WORKSPACE and BUILD layout shown in the issue, comparing @norden//... with //.... Trace the query handling for subworkspaces and verify completion when the results match the expected workspace boundary and the @bbi//... example no longer loads the nested repository as part of its parent.

Written by the indexing model from the issue text.