feat: enforce maximum subnet state size from registry in DSM

[mraszyk]

This PR enforces the maximum subnet state size from the registry's subnet record in the DSM.

In more detail, this PR

• adds a field own_resource_limits to SystemMetadata in ReplicatedState (preserved across checkpoints and overridden at the beginning of every round based on the registry value);
• uses that field to refine subnet_memory_capacity in ExecutionEnvironment;
• makes resource limits configurable in StateMachine and ExecutionTest frameworks.

The subnet resource limits are passed to ExecutionEnvironment via a field in SystemMetadata so that they are also available to non-replicated execution (query handler) which does not have access to the registry.

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

Done

[schneiderstefan]

Would it be possible to break that down into smaller, reviewable, PRs? Maybe start with the registry, and ignore it in the new fields in the replica in the first PR. The rest could also be broken down into refactor and reading the registry.