Discoverability of migrations affecting a feedstock from its README

For people less familiar with conda-forge, it's often difficult to understand how things work. There are lots of bots and infra bits happening, and it can be overwhelming or at least hard to understand.

One pattern we tend to see for popular pytorch-dependent packages, is that people are repeatedly raising issues that amount to "the relevant migration has not happened yet". There's an adjacent topic of the metadata not _necessarily_ matching the tighter pins that pytorch's PyPI packaging imposes (because they want to avoid a combinatorial explosion of packages to test/support), but that's not important for this issue. Examples:

- https://github.com/conda-forge/torchvision-feedstock/issues/141
- https://github.com/conda-forge/torchvision-feedstock/issues/134
- https://github.com/conda-forge/torchvision-feedstock/issues/130
- https://github.com/conda-forge/torchvision-feedstock/issues/129
- https://github.com/conda-forge/torchvision-feedstock/issues/119
- https://github.com/conda-forge/torchaudio-feedstock/issues/25
- https://github.com/conda-forge/torchaudio-feedstock/issues/27
- https://github.com/conda-forge/torchcodec-feedstock/issues/43
- https://github.com/conda-forge/torchcodec-feedstock/issues/45

Despite having https://github.com/conda-forge/torchvision-feedstock/issues/135 pinned, these issues seem to keep coming; the sheer number also implies that we could do better on clarity here.

In the most recent example, a user [suggested](https://github.com/conda-forge/torchvision-feedstock/pull/143) a note to the feedstock README. That's a fine approach in principle, but has several problems:
* the feedstock README gets destructively updated by smithy (though it's possible to abuse the feedstock `description:` for persistence)
* any static information will necessarily become stale, and will on balance (I believe) lead to more confusion than it resolves
* parking such information in the `/recipe` README is even less discoverable than a pinned issue.

Summing up, IMO we should improve this situation, so that the users and contributors can successfully discover the relevant information by themselves. But doing this on a per-feedstock basis is a fool's errand. It needs support from our infrastructure, hence this issue.

I don't know how this could look like exactly - we cannot know in advance all the migrations that might affect a feedstock, or even their naming pattern (for example, [this one](https://conda-forge.org/status/migration/?name=absl_grpc_proto_26q1) migrates multiple libraries at once). The only way that would IMO make sense conceptually is to have a sort of "reverse search" of "which migrations is this feedstock currently a part of", which could in principle be deduced from the graph metadata that we have already. If such a reverse search existed, we could then add a link to each feedstock README (via smithy) that points to the result of this search (for the feedstock in question).