feat: alternative inter-realm implementation

[thehowl]

This is a different attempt at the same goal of #2958, attempting to implement a different set of rules.

---

• At the end of a cross-realm function call, any unreal object reachable by the realm's real objects becomes real, and with the owner set to that function's realm.
  • Why: anything a realm decides to persist should be that realm's responsibility to store and keep stored.
  • A realm may not attach types declared in another realm (though it may reference them).
    • Why: the methods of a realm's type should always consider as being
  • If a panic crosses a realm boundary, it is no longer recoverable.
• A cross-realm function call must always return real references, or values.
  • Why: getting a reference value from another realm should be "safe" in knowing that the cost of storing that reference is constant (the cost of the reference), rather than also of the returned object.
• When an object is real, it has an owner. Only its owner is capable of modifying the object.
  • The PackageValue of a pure package is recursively owned by a pseudo-realm, which doesn't allow modifications on these values after they've become real.
    • Why: all values in a pure package should be permanently immutable, both by that same pure package, other pure packages and all realms.
• A method call is considered the same as a function call to where that method is declared.
  • i.e.: If it is a pure package, the realm is the maintained the same as the caller. If it is a method in a realm, it is switched over to that realm.
  • Why: methods should not be considered special. Switching behaviour on the attachment of the receiver also makes it hard to understand what realm the function should be executed in. Also this makes methods work the same whether they're on a real or unreal value.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: thehowl/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission