Expose target wildcard matching to Starlark

### Description of the feature request:

Please expose Bazel's capability of matching target labels against wildcards to Starlark. Given a list of target patterns and a list of targets, return the list of all targets that match any of the given patterns. Patterns should have the same feature set as patterns allowed on the command line. E.g. specific `//package:target`, wild-card `//package:all`, or `//package/...`. Optionally, it could allow patterns relative to a specific target, e.g. `:all` matching all targets in the same package. Here's a suggestion of what the API might look like:

```
def match_targets(patterns, targets, relative_to = None):
"""
Args:
patterns: List of patterns.
targets: List of target labels.
relative_to: Match relative patterns relative to this target.

Returns:
List of labels contained in `targets` that match any of the given `patterns`.

"""
```

### Feature requests: what underlying problem are you trying to solve with this feature?

The use-case that prompts this feature request comes from `rules_haskell`, where we would like to implement a [REPL rule based on an aspect](https://github.com/tweag/rules_haskell/pull/736) with the following interface:

```
haskell_repl(
name = "my-repl",
# Collect all transitive Haskell dependencies from these targets.
deps = [
"//package-a:target-1",
"//package-b:target-2",
],
# Load targets by source that match these patterns.
from_source = [
"//package-a/...",
"//packaga-b/...",
"//common/...",
],
# Don't load targets by source that match these patterns, instead load their binaries.
from_binary = [
"//package-a/vendored/...",
],
)
```

See below for some background and motivation.

Currently, we re-implement a subset of Bazel's target pattern matching in Starlark to enable this interface. This is duplicated effort that should not be necessary. And we would prefer to offer our users Bazel's full pattern capabilities.

Note, that we cannot use [`genquery`](https://docs.bazel.build/versions/master/be/general.html#genquery) in this case, because it does not allow wild-cards, and also does not take configuration into account (`query` vs. `cquery`).

#### Background on Haskell REPL

With Haskell's REPL there is an important distinction between loading a target by source or as binary. If you load by source, this allows you to modify the source file, instruct the REPL to reload sources, and observe your code changes in the REPL right away, allowing for a fast feedback loop. Loading by binary instead means that code changes only become visible if you close the REPL, rebuild the binaries, and reopen the REPL. In practice this is too slow for productive development.

However, some targets should not be loaded from source, but instead as binary. Reasons for this could be that they require compiler flags that are incompatible with other modules, or you're not interested in modifying their source and want the speed benefit of loading them as binary.

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

[NixOS](https://nixos.org/)

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

release 0.23.1- (@non-git)

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

Using the [Nix package manager](https://nixos.org/nix/).

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

Only `genquery` which is not applicable.

Start by examining the existing genquery behavior and Starlark extension points; the issue names no source files or tests. Completion would be a Starlark API that matches the listed command-line target-pattern forms, optionally handles relative patterns, and returns matching targets with configuration-aware behavior.

Written by the indexing model from the issue text.