SOGNO: a proposal for refactor+reflect+gc

[thehowl]

A large VM change proposal to include Reflection, GC, fully-deterministic maps,
improved debugging, improve performance, defining realm ownership, and
efficient realm storage, add Unit Tests to many missing areas and possibly,
fix many outstanding issues

This PR serves as an introduction of my "dream" which I've thought up last Saturday following a number of conversations and my own considerations after terminating the first phase of GnoChess.

This is a proposal for what I would like to work on and experiment on, alongside work on the monorepo development, over the coming months. It is a collection of many features which would generate many PRs on the monorepo, with the ultimate goal of achieving my "dream", OR: what I wish Gno was when starting to work on GnoChess.

I invite you to take a look at the rendered document, and add your comments, thoughts and feedback. Please do not merge this PR.

Introduction

(From the top of the complimentary document -- read there for better rendering!)

Sogno means "dream" in Italian, and is pronounced with the "gn" cluster in the
same way as "ñ" in Spanish. Check Wikipedia
for more info.

The following proposal comprises of a large list of features and
improvements I would like to see and experiment with in the GnoVM. Most of these
have arisen from issues I've encountered working on GnoChess.
Reflection is necessary for good JSON encoding, unclear functioning of Realm
Ownership lead to many issues popping up in that regard, and a lack of good
debugging support made finding root causes of issues very hard at times.

The following is a wishlist of large areas I would like to work on myself. The
reason why I am compiling them all together in a big Hackerspace issue is that I
would like to embark on a journey to try to implement this in my own fork on
GitHub, following the solo voyager
workflow already undertaken by many of us in different projects.

The plan would thus be to implement each feature in order on separate branches,
stemming from the gnolang/gno master branch directly, and create gradual PRs
comprising the refactor / proposed changes for each feature. The difference from
our normal monorepo workflow, though, is to continue development without
necessarily awaiting for merging on upstream: the goal is to arrive at this
entire featureset being developed and ready to test as early as possible, in
order to have a full "dream" experience for anyone to test and try out.
The idea is to try to create a "next generation" experience for developing Gno
code, where many of the areas that I currently identify as critical are greatly
improved.

I don't intend to create an independent, "spinoff" fork, and for this purpose as
much as possible I'd want for changes on the Gno monorepo to be synced to the fork.
The reader may understand that such big changes not in sync with master entail
spending hours on merge conflicts; but I think I decently know my way around them
and I am prepared for that ;).

The goal is not necessarily to have the entirety of these features merged into
the upstream, as obviously each one of these will need to undergo review &
understand if it is the right way to go independently. I expect some of these to
be merged only after extensive review & changes, and maybe a few rejected after
careful consideration (hopefully deciding for a different approach to tackle the
underlying issue). However, my idea would be that of embarking on a journey to
quickly iterate and try to bring in a timely manner many of the critical changes
I currently see to the Gno language's usability, and the clarity of the
implementation.

A note on contribution and collaboration: if somebody wants to help on any of
the following topics (ie. by also working on the code and iterating quickly with
me) you are welcome to ask me to join & take on a part of the work. I don't need
this to be done all by myslef, I need all of this to be done and working. The
"solo voyager" workflow is referenced only because I still intend to work on a
philosophy of being able to quickly develop a lot of features and reach my
"dream" as early as possible, while not removing the adequate time we need to
review and consider merges on the master branch.

[moul]

Blocking, as requested by the author.

[thehowl]

Closing in favour of other approaches and smaller scopes (like gnolang/gno#1374)