Document the release process / expectations

## Done Criteria
We have a durablble document that covers Helia's release philosophy and mechanics, and is easily discoverable.

## Why Important
Releases are our delivery mechanism for translating the great development work into a form that consumers can easily use.
We want it documented:
1. for resieliency so we're not reliant on tribal knowledge
2. helps build confidence and set expectations for consumers
3. gives insights to other contributors

## Notes
Specific steps I assume we'll need to take:
- [x] Create a durable document like RELEASE_PROCESS.md
- [ ] Add a link to the release process document from a `Release Process` section in the README

Questions I think the doc needs to answer:
- [ ] Who does a release?
- [ ] How often do we release? Basically help answer for someone what the triggering conditions are for a release. Is it whenever maintainers feel like it, when someone asks, time bound? I want to make sure we set people's expectations appropriately.
- [ ] What relationship do Helia releases have to js-libp2p releases? For example, if there's a new js-libp2p release, what's the upper bound we'll go before issuing a new Helia release?
- [ ] What are the steps in doing a release?
- [ ] Some description/overview of the machinery under the covers that does the automation
- [ ] Is there anything we have to be sensitive when doing releases (e.g., we don't do them on Fridays)
- [ ] What to do when a commit makes it in that doesn't follow the expected naming format
- [ ] Do we do any editorializing on top of the release to notes to give a "tldr" or "what matters in the release". (I think it can be important for to make sure we step back and think about why this release matters for consumers beyond bullet points of one liners)
- [ ] Where do we document migration or upgrade steps?
- [ ] Is there any manual testing or can the release happen as long CI is green?
- [ ] What announcing do we do after the release? (I think ideally we should make a discuss.ipfs.tech post which also posts into chat, and a blog.ipfs.tech post which just redirects to the release notes)
- [ ] After there's a Helia release, do we proactively update the version anywhere (e.g., other helia repos, helia examples).

I know I'm throwing a lot here. I do think it's better for us to get something going that we progressively add to than nothing.

Potentially related documents to draw from that answers a lot of the questions above for their context:
1. Boxo: https://github.com/ipfs/boxo/issues/170
4. Kubo release process: https://pl-strflt.notion.site/Kubo-Release-Process-5a5d066264704009a28a79cff93062c4
5. Kubo release steps: https://github.com/ipfs/kubo/blob/master/docs/RELEASE_ISSUE_TEMPLATE.md