Document support policy around external use of conda-forge-packaged compilers

### Where should the content be added?

Somewhere more user-visible than the maintainer docs?

### What should be added?

In a recent core discussion, it came up that
> @beckermr: [...] However, some folks do use our compilers outside of conda-forge and so it may be that they don't want [some conda-forge-internal thing]

I asked:
> [...] Speaking of the compilers, how explicitly do we support use of them outside of our own ecosystem, beyond what we provide through the `compilers` package (which is heavily caveated)? Do we have anything on that written down somewhere?

Since it seems we don't have much that covers someone using (for example) `gcc_linux-64` or `clang_osx-64`, and what expectations about continuity, stability, and lack of cf-internals users of such packages can make, I thought I'd open this issue.

I don't have a strong opinion either way, but I think we should document what we're willing to support (or not!).

Sidenote: support for our compiler stack (resp. lack thereof) is partially documented in `src/maintainer/infrastructure.rst` (though quite outdated), and the promises we make about this was a point of discussion in https://github.com/conda-forge/conda-forge.github.io/pull/1950

### Additional information

_No response_