PR #306 rebuild: allocator-aware AML interpreter branch

[SnowCheetos]

Context

This is the main replacement for the allocator API portion of rust-osdev#306. It should be rebuilt from clean upstream/main after the smaller platform/global-lock PRs are separated.

Maintainers are open to allocator support, but rust-osdev#306 is not reviewable as a single branch.

Scope

Rebuild allocator support for AML interpreter storage with a clean, reviewable history.

Likely implementation areas:

• Make AML-owned objects and namespace storage allocator-aware.
• Add explicit *_in constructors where an allocator is needed.
• Preserve Global as the default allocator.
• Preserve existing new constructors where possible, with new_in for custom allocators.
• Update AML tests and helper tools only where required by the allocator-aware API.

Constraints

• Start from current upstream/main, not from PR Make AML interpreter storage allocator-api compatible rust-osdev/acpi#306 history.
• Rebase instead of merging upstream.
• No generated/autocommit commit bodies.
• No version bumps unless maintainers explicitly ask.
• No unrelated interrupt/resource/global-lock/platform changes.
• Minimize formatting-only churn and respect rustfmt.toml.
• Avoid unnecessary macro/op-method churn.

Suggested commit structure

1. aml: add allocator parameter to owned object storage
2. aml: thread allocator through namespace storage
3. aml: add Global-default constructors
4. aml: update test tools for allocator-aware interpreter

Adjust as needed, but each commit should be reviewable on its own and explain the rationale.

Acceptance criteria

• Branch contains allocator work only.
• Interpreter::new remains available for Global.
• Interpreter::new_in or equivalent exists for custom allocators.
• String/error strategy follows the decision from the allocator prep issue.
• Tests pass for library and affected AML tooling.
• PR description explicitly links to the superseded Make AML interpreter storage allocator-api compatible rust-osdev/acpi#306 and summarizes design tradeoffs.