Create updated release process

[BigLep]

Done Criteria

There is a clear set of documented steps that a "release engineer" can follow for cutting.
Outdated documents (example maybe) are updated or removed.

Why Important

Release processes as tribal knowledge have the problem of:

1. Doesn't survive if tribe members leave or are away. Others "groping around" may make mistakes which takes more time later.
2. Less likely that lessons learned or improvements will be captured and passed on.

User/Customer

Maintainers

Notes

1. During the nv23 release process, it seemed that we didn't have the list of steps needed for cutting a release, especially when older versions also needed to be updated. See comment in Release for FIP-0090/0092 #2013 (comment) .
2. There are steps around fvm_integration_tests. See Release for FIP-0090/0092 #2013 (comment) and https://filecoinproject.slack.com/archives/C029MT4PQB1/p1718240205547329
3. There is currently this document form a couple of years ago: https://github.com/filecoin-project/ref-fvm/blob/master/doc/testnet-release-process.md that should be updated or removed.

[Stebalien]

1. The fvm_integration_tests issue would be solved by automatically publishing releases to crates.io whenever the version gets bumped.
2. We definitely need some CI for a dry-run (CI: Publish dry-run #2004) publish to catch issues.
3. We need documentation for updating proofs and wasmtime. We usually don't release v2 & v3, but I try to do so whenever I update the proofs library and/or wasmtime to reduce code bloat due to duplicate crates.

[rjan90]

• We should remove the outdated document, and rather move/create a doc on "how to update ref-fvm dependency in Lotus"