PR #306 allocator prep: decide string and error strategy

[SnowCheetos]

Context

Maintainer feedback on rust-osdev#306 called out two allocator-design concerns that should be resolved before rebuilding the allocator PR:

• A home-grown AmlString<A> may not be desirable; string_alloc may be a better fit if allocator-aware string storage is needed.
• AmlError<A> is a design smell, especially where it complicates PartialEq and error handling.

This issue is the design checkpoint before more branch surgery.

Questions to answer

• Can AML string storage use string_alloc instead of a custom AmlString<A>?
• If not, can a custom AML string type be isolated in its own module with a small API surface?
• Can AmlError stay non-generic by avoiding allocator-owned payloads?
• If error redesign is necessary, should it be a separate preliminary PR?
• Which allocator bounds are truly required at public API boundaries: Allocator, Allocator + Clone, Allocator + Clone + 'static, Send, Sync?

Acceptance criteria

• Written decision on string storage approach.
• Written decision on whether AmlError remains non-generic or gets redesigned first.
• Any required preliminary PRs are identified.
• Replacement allocator PR plan is updated before implementation.
• Commit messages for allocator work explain these choices rather than burying rationale in generated text.