Add rapid_analysis to lsst_distrib (or other metapackage)

A SITCOM package called rapid_analysis exists, which provides many utility functions for observers and commissioning scientists on the summit. Currently it is AuxTel-specific, and this is very much by design† - this is not intended to provide tools for other observatories. Furthermore, while it mostly plays by the DM rules/coding standards, it does not always, again out of necessity - the package is for working live and performing non-pipeline-types of analysis, so a certain amount of pragmatism is necessary, though it is kept to a minimum wherever reasonably possible.

Given that it is required by observers and commissioning scientists (not to mention a growing number of users) it is unfortunate that it both does not currently benefit from our CI system††, and also requires manual installation on the summit by anyone who wishes to use it, despite it containing code that observing depends on.

This RFC is to discuss adding it to our distribution. I am agnostic about whether it should go into lsst_distrib, or whether a new metapackage, which would be a superset of lsst_distrib, be created to house it (and potentially other commissioning tools). Personally, I'd lean towards not (yet) creating a new metapackage, and instead moving some of the more "core" packages "up" to lsst_apps†††, thereby making lsst_distrib closer to how it was originally intended to function, and allowing this in (not to mention that this is just less friction, and deployments don't then have to name a new metapackage as their target), but if people have strong feelings on that, they can be discussed here.

The intention is to add the package only after DM-31522 has had its lengthy review comments addressed and is merged.

†Whether it expands to also serve ComCam and LSSTCam in the future, or whether it gets renamed to something AuxTel-specific, or whether it's refactored to rapid_analysis_base etc, is, I believe, beyond the scope of this RFC, though surely those fill follow in the coming months.

†† Though I'll be the first to admit it could use some more tests.

††† Not as part of this RFC, I just know this is something that Kian-Tat Lim has been thinking about, and it seemed relevant to mention that this is already being considered.