Make the diagnostic message clear between `unknown` vs `unsupported` vs `unbuildable`

Nobody has claimed this yet.

We’ve started using the term “unsupported” for a bucket of things that should be more clearly divided.

The term “unsupported” means “the target machine is known (to at least one tool chain) but is never possible to build on this host machine”. For example, Windows targets are unsupported on macOS machines.

The term “unknown" means "the target machine is not known (to any defined toolchain) and we will never know how to build”. For example, architecture `foo` with any tool chain declaration defaults because we don't know how to discover a tool chain that could build architecture `foo`. With better tool chain discovery, architecture `arm` could be buildable on VS2017+ as it provides the right tool chain for it. It would then be considered either "unbuildable" on Windows or "unsupported" on other OS. However, if we precisely configure tool chains with no explicit configuration for `arm` then it would be considered "unknown".

The term "unbuildable" means "the target machine is known (to at least one tool chain) but is not possible to build as it wasn't found on the current host".

Gradle should never fail at configuration time when an “unsupported” or "unbuildable" target machine is included in the set of target machines for a component. But it is ok to fail when an “unknown” target machine is included in the target machines for a component. The distinction is important to make.

No files, tests, or entry points are named. Start by tracing where target-machine classification and configuration-time diagnostics are implemented. Done means the diagnostics distinguish unknown, unsupported, and unbuildable targets and apply the stated configuration-time failure behavior.

Written by the indexing model from the issue text.