gnoland/gnovm: purify `p/` even more

[moul]

gnoland/gnovm: purify `p/` even more

[leohhhn]

On top of this, we should disable direct calls to Gno stdlibs via maketx call (refrence comment).

@moul, I think its okay that p/ has top-level variables such as constants, since these can be useful. This is currently possible - read about it in this issue.

Closing #2224 in favor of this.

[ltzmaxwell]

@moul, I think its okay that p/ has top-level variables such as constants, since these can be useful. This is currently possible - read about it in #1538.

I think that p/ should be OK to contain package-level variables.

While the following is off-topic:

It's peculiar that you need to constantly remember that this is a p/ and that the variable isn't meant to be persisted, similar to how you must be mindful that it will be persisted when working within a Realm (comment in packages in r/). All these rules are implicit, which can be confusing.

[moul]

For p/, package-level constants are allowed, but variables/state that can change are not. The Go linter should prohibit this.

Do you have examples of package-level variables that would make sense?

[ltzmaxwell]

I mean something like this:

errXXX := errors.New("a common error shares within packages").

gno/examples/gno.land/p/demo/flow/io.gno

Line 14 in 28111d9

var ErrLimit = errors.New("flowrate: flow rate limit exceeded")

but of course, we actually don't want to modify it.

[leohhhn]

Prohibit the use of maketx call with a p/ entrypoint.

Completed in #2242. We could make the error a bit more informative: invalid package path