Define and document workflows for librt updates

[JukkaL]

We now have the project librt on PyPI (GitHub link, PyPI link) that has functionality that mypy cache (de)serialization depends on (at least when using an interpreted mypy). It's a C extension that is based on the code under mypyc/lib-rt. We'll need to publish a new version of librt if we change certain things in mypyc/lib-rt, and it's important that multiple maintainers are able to do this so that this wouldn't block mypy/mypyc releases or development.

Here are things we need to define/document:

• Have at least 3 experienced maintainers that have enough access and knowledge to make librt releases (both GitHub and PyPI project access). We need at least two owners so that we can also give access to new maintainers as needed and revoke access.
• Decide where to put the relevant documentation (Mypy GitHub wiki? File in the librt GitHub repo?).
• Document how to make a librt release somewhere in the mypy repo (possible just a link to a doc in the librt repo).
• Document when we need to update the librt pin in mypy-requirements.txt and test-requirements.txt.
• Document when we need to release a new version of librt (after every lib-rt change or only before a mypy release?).
• Document how to make backward incompatible changes to librt, with a detailed description of PRs and timelines. E.g. we'll need to keep old functions in capsules around indefinitely, so we'd always need to add a new function but also keep the old one. Also some backward incompatible changes are probably not supported.
• Document how versioning works.

cc @ilevkivskyi

[ilevkivskyi]

@JukkaL I sent you an invitation couple weeks ago to own librt on PyPI. The (short) release instructions are in librt repo, we can link them in mypy developer docs. Btw since I have set up trusted publishing, everyone who has permissions to run actions in mypyc org can publish a new version on PyPI by simply triggering the workflow on a tag.

Btw about pinning: I was thinking it may be better to actually pin the librt version for one-two mypy releases (because currently we don't) to simplify development of librt.internal while it is still active (like adding support for two byte integers, add type tags for primitive types etc). We can discuss it offline probably.

[JukkaL]

Sorry, I missed the invite and the token has expired. Can you send it again?

[ilevkivskyi]

Just sent you a new invite.

Btw while we are talking about this, can you give me some permissions to mypyc org that will allow me to update its "profile picture"? I wanted to make it more "official" by using the mypy logo there https://github.com/python/mypy/blob/master/docs/source/mypy_light.svg (or maybe just the left part of it, i.e. the blue-grey version of the Python logo, since an org "profile picture" is supposed to be rectangular).

[JukkaL]

@ilevkivskyi You should now have access to update the profile picture.

[A5rocks]

Document when we need to release a new version of librt (after every lib-rt change or only before a mypy release?).

Probably every interface change so that people using pre-release builds of mypy will be fine? (or even mypyc builds in CI?) e.g. the person in #20006

(I guess we could provide librt wheels in the mypyc-wheels repo, but then an exact pin wouldn't work I think)