feat: use golang workspace

[gfanton]

This PR introduces individual go.mod files for gnovm, tm2, and gno.land. It should help visualize and manage Go dependencies. I'm not sure if we should push the go.work file or not. Personally, I think it could be good to keep it until we have independent releases for each Go module.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[moul]

Yes, multiple go.mod files are used to reduce the size and complexity of indirect dependencies for the current project. We have plans to extract tm2 from the monorepo in the future. This approach also simplifies dependency tracking and allows for different philosophies per package.

As for workspaces, I don't have personal experience with them. However, based on my understanding, they can potentially eliminate the need for excessive use of require ../ statements and make it more convenient to use "go get" to install remotely.

[gfanton]

From my understanding, and after some digging, I've come to a misconception about how workspaces function. Workspaces aren't specifically meant to be pushed and are more useful for local development, overriding module inner dependencies. In their current state, we cannot use workspaces. Or we can, but I don't think it's worth it until we manage individual versioning for each module.
Closing it for now.