Adding `host_exports` (like `run_exports` except between `build` & `host` only)

`run_exports` has been immensely helpful. Just to summarize it `run_exports`:

* Allows packages with knowledge of what they need to express it for easy downstream consumption
* Packages that are part of the build can add dependency to `run`
* `weak` only happens when the dependency is added to `host` (not `build`)
* `strong` happens when a dependency is added to `build` or `host`
* Dependencies added can express ABI compatibility

However there are still some cases that are not covered. In particular there are cases where a dependency added to `build` needs to add itself to `host`, but there is no need to add it to `run` (in fact this would often be better to avoid). IOW `run_exports/strong` does not meet this need. Some examples include:

* Header-only dependencies of a package
* https://github.com/conda/conda-build/issues/3796#issuecomment-549431589
* Tighter alignment in `build` & `host` of compiler dependencies (like OpenMP)
* https://github.com/conda-forge/openmp-feedstock/issues/126
* Compiler runtime libraries that are statically linked (like `cudart`)
* https://github.com/conda-forge/staged-recipes/pull/21723#issuecomment-1405444862
* Other compiler use cases
* https://github.com/conda/conda-build/issues/3966

Solving these cases would involve a `host_exports` that allows adding other dependencies to `host`. Could imagine to use cases for a package providing `host_exports`

* `host_exports/weak` (default)
* Add dependencies to `host` if providing package is added to `host`
* Solves the header-only dependency case above for a library
* `host_exports/strong` (opt-in)
* Add dependencies to `host` if providing package is in `build` or `host`
* Handles the compiler dependency alignment problem (with OpenMP)
* Handles statically linked compiler libraries (like `cudart`)
* Of most use for compiler use cases