Contributing policies for adding/updating new stdlibs packages

[moul]

Multiple times, it happened to me that I missed a stdlibs package or method. We need to make it possible to add new stdlibs packages or update already imported ones.

I suggest:
We add a dedicated section with clear rules in CONTRIBUTING.md, let's say: "make sure the package compiles with no dead/incompatible code", and "make sure that the code allows making deterministic.", "make sure to keep the copyright", and "keep some unit tests".
Bonus: develop a small codegen script that takes a configuration file to regenerate all the stdlibs we want, and remove every function we don't want.
Bonus: if we get this configuration file from above, we could also generate an automatic changelog.

@jaekwon Before opening the first PR by myself to fully experiment with the process with some stdlibs I miss, I would like to know if you have any feedback about what you did in the past? Maybe you have already developed some helper scripts?

FYI, I plan to update "strconv" which lacks some recent Unicode helpers that I need in testing.

[moul]

Related with #486

[moul]

Update

We should also make a process for porting good go libraries to gno, and publish them under a special domain prefix.

• gno.land is for the main GnoVM chain; the sources are published using TXs.
• foobar.land is for a new GnoVM chain; the source will be fetched using IBC2.
• github.com or maybe imported.land/github.com is a special prefix where we know that the publisher is not the actual author, the license is inherited from GitHub, and the original author will be able to claim ownership later.

---

That being said, we can't have a process to port existing libraries without supporting versioning:

• import "gno.land/p/stuff" could be the alias of gno.land/p/stuff/a1b2c3d4, updatatable to a newer version.
• import "gno.land/p/stuff/5e6f7g8g" is the exact version.

---

Maybe make something equivalent for the stdlib, and manage #486 by adding a new version.