Tutorial for builtin-actor development

[BigLep]

Done Criteria

There is a tutorial(s) for doing builtin-actor development and getting those changes into Lotus.
Since this focuses on getting changes into Lotus, the docs probably belong in Lotus, and then a pointer to those docs can be in builtin-actors' readme.

Why Important

FilOz wants to empower other people/teams to do this work. One part of doing this is pointing to an example for the steps involved.

User/Customer

New builtin-actor contributors (e.g., new FIP implementers)

Notes

1. There are multiple tiers of change going from easier to harder:
   1. No new method methods
   2. New/changed methods (e.g., serialization change). This involves having corresponding go-state-types change
   3. Change in ref-fvm or proofs
2. In 2024Q3, we expect this to be helpful at the minimum for having others help do FIP-TBD: Export sector termination method from miner actor FIPs#1035 and/or Supporting EIP-5656 (MCOPY opcode) in the Filecoin EVM runtime FIPs#1025

[BigLep]

Assigning to @rjan90 said in https://docs.google.com/document/d/1NgD_Rza3sUfDbyV4dbAs9D4SmXrWJwk9OdkL5UHszu8/edit that he would take this in support of #1572

[BigLep]

@rvagg : can you drop some notes about this based off what you have done for filecoin-project/lotus#12526 ? Feel free to comments here and @rjan90 or I can turn it into a doc.

[rvagg]

Follow-up on what I already landed: the discussion with Mikers in Slack about MCOPY made me realise that I've made it sound too simple and even that first section needs a revision. Some thoughts about the deficiencies:

• The text assumes that you can do a network upgrade from nvX to nvY, and that putting a new builtin-actors bundle in for Y will be fine.
• Lotus requires that we have a ref-fvm that supports version Y in order for it to perform a migration and start mining on that network version.
• There is a process we have in place for bumping this in ref-fvm and bubbling those changes up to Lotus, so once that's done this isn't a problem, but before it's done, the docs need nuance.
• The docs should probably outline the ref-fvm dependency upgrade problem for a new builtin-actors, for educational purposes.
• The docs could instead suggest that if you're just doing builtin-actors dev, then without a ref-fvm update in place, you could just do it for network verison X, i.e. the current one, so install your actors with that network version, replacing what's there, and test against that, knowing that your final version, when it lands, is probably going to need a ref-fvm update (by someone else) and to have version Y in place where your builtin-actors changes are likely to land.