cue/load: support package pattern wildcards beyond the current module

[mvdan]

To fix #3155, https://review.gerrithub.io/c/cue-lang/cue/+/1195195 takes an approach where package patterns with wildcards like ./... are only supported if they use the current module as a prefix, i.e. they aren't meant to match any external modules such as existing or missing dependencies. This is the simplest kind of wildcard to support, as it's very similar to filesystem globbing like **/, given that all possible matches are in the local current module.

Supporting arbitrary patterns with wildcards to query packages or modules may be problematic for a number of reasons:

• They could take a long time; shoud .../foo match all "foo" packages across all CUE modules ever published?
• They could require many requests to registries, particularly when trying to discover which modules may exist or contain a package.
• They could be more complex algorithms; a wildcard matching an unknown number of modules might need to keep updating the module graph due to MVS.

This issue is mainly to capture what kinds of use cases people might have for package (or module) patterns beyond the current or local module.

[rogpeppe]

• They could take a long time; shoud .../foo match all "foo" packages across all CUE modules ever published?
• They could require many requests to registries, particularly when trying to discover which modules may exist or contain a package.
• They could be more complex algorithms; a wildcard matching an unknown number of modules might need to keep updating the module graph due to MVS.

Note that in practice Go does not support patterns of that form, as it almost always fails
because of missing go.sum entries.

For example, in the CUE project itself:

% go list .../qt
pattern .../qt: cloud.google.com/go/compute/metadata@v0.3.0: missing go.sum entry
% go list ...
go: updates to go.mod needed; to update it:
	go mod tidy

So I think it would probably be reasonable to restrict pattern matching outside the
current module to patterns that begin with a non-wildcard prefix that corresponds
to a module name.