feat(stdlib): add path package

[gfanton]

simply add path package to stdlib, needed by net/url package (and probably some other packages)

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.

[thehowl]

I've had a look through the Go native implementation. There doesn't seem to be any dependency on packages/features we can't currently support (imports are on errors, utf8 and internal/bytealg, all of which already exist as packages, and I don't see any channels/goros being used).

Could we have this as gno code instead of a native injection?

Also, gnovm/docs/go-gno-compatibility.md should be updated, too. :)

[gfanton]

I've had a look through the Go native implementation. There doesn't seem to be any dependency on packages/features we can't currently support (imports are on errors, utf8 and internal/bytealg, all of which already exist as packages, and I don't see any channels/goros being used).
Could we have this as gno code instead of a native injection?

Sure, that make sense! I wasn't sure about preferring one location over another. I thought that if no modifications were needed, or if there were only a few methods to add, it would be more efficient to place this directly in the stdlib file rather than creating a specific gno package directory.

[thehowl]

I thought that if no modifications were needed, or if there were only a few methods to add, it would be more efficient to place this directly in the stdlib file rather than creating a specific gno package directory.

In general, let's work towards keeping stdlibs.go injections as few as possible. They should be like C extensions in Python: they are possible and sometimes necessary, for either doing impossible/hard things in the VM language (Gno), or because of performance (and then again, isolate specific functions which need them).

Impossible/hard things include, for instance, any use of unsafe (ie. math.Float64frombits), or crypto (crypto/sha256), which is why those are injected.

strconv is currently native but I don't think all methods there are good candidates for native injections. They are still native in #859, but I'd like to change that in the future.