Provide hooks for host platform autodetection

### Problem description

With https://github.com/bazelbuild/bazel/issues/7081 we will get a nice repository rule that will autodetect the host platform target. This target will be used as a default value of the `--platforms` and `--host_platform` Bazel options, and also as the default execution platform.

Currently the autodetection detects the cpu and os and selects the right constraint from https://github.com/bazelbuild/platforms. This means that any Bazel toolchain that uses at most these 2 settings will be selectable by this platform.

But that is not enough for toolchains that define custom constraint settings. For those toolchains to be selected we need to put their constraints into the host platform. And those toolchains will very probably need to perform some kind of host system inspection to properly tell which constraint value to add.

### Alternatives

#### Platform inheritance

One solution is to tell users to create their own platform target that inherits from the autodetected host platform. User will be responsible for making sure to collect all the constraint_settings from all the toolchains in their build and make sure they are represented in the inherited platform. Then they have to direct `--platforms` and `--host_platform` into their inherited platform target.

With this approach very few projects will end up using the default value of `--platforms` and `--host_platform`. This is not great and goes against the grain of 'flagless builds` effort of the configurability team.

#### Hooks into host platform autodetection

This approach makes advantage of the observation that all these toolchains are already being registered in the WORKSPACE file and they potentially already perform the autodetection for themselves. What we need is to pass a list of labels from these custom repository rules to the `@local_config_platform` rule.

##### Explicit approach

User will have to collect generated constraints from all their rules (e.g. rules will write a `please_put_these_constraints_into_host.bzl` file in their repo, the user will load that bzl file in the WORKSPACE, and use a constant from there), call `local_config_platform` manually, and pass constraints as an argument to the call.

* Advantages:
* no need to change default values of Bazel options
* Disadvantages:
* need to collect transitive constraints from rules repos
* need to call `local_config_platform` manually

##### Implicit approach

We will figure out a way to allow rules to hook directly into `local_config_platform`. I have no idea how that would look like. Maybe the audience has ideas :)

* Advantages:
* no need to change default values of Bazel options
* no need to call `local_config_platform` manually
* no need to collect constraints
* Disadvantages:
* it's a kind of magic

Start by reading the host-platform autodetection described in issue 7081, then trace how WORKSPACE repository rules and @local_config_platform interact with --platforms and --host_platform. Done means there is an agreed design for custom repository rules to provide constraints to host-platform autodetection without requiring users to manually collect them or invoke local_config_platform.

Written by the indexing model from the issue text.