gnoland/gnovm: purify p/ even more

[moul]

Currently, p/ packages lack a data state (global vars) and cannot import r/ (EDIT: they can), which is great. Yet, there are remaining ambiguities with r/ to resolve for clarity and ensure they are entirely pure and stateless.

Essentially, p/ should be seen as a platform for sharing source code among developers, while r/ is where apps (and some dependencies) reside for users to interact with.

Changes to consider:

• forbid importing realms from pure packages (r/ from p/) #3040
• Prohibit the use of maketx call with a p/ entrypoint. feat(sdk/vm)!: only allow using msgcall on realms #2242
• Retain q_eval for now.
• Trigger a panic if a p/ attempts to create a banker, but allow interaction with an already instantiated banker from r/. feat: avoid Instantiation of banker on pure packages #2248
• Conceal std.DerivePkgPath for p/ and emphasize their unique identifier, PkgPath. Consider using std.GetCallerAt() Frame to prevent p/'s std.Address from appearing in logs and causing confusion.

cc @leohhhn

[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

[moul]

Related: #2459