Add stage-2 MMIO handler support

[zhangxp1998]

Summary

• Add stage-2 memory access handler support for trapping selected IPA ranges.
• Add typed read/write handler APIs so write handlers cannot return read results.
• Add a QEMU filtered MMIO test page and integration coverage.
• Support platform-specific binary make targets.

Tests

• cargo fmt --all -- --check
• git diff --check
• make build PLATFORM=qemu
• make clippy PLATFORM=qemu
• make test PLATFORM=qemu
• git show --check upstream/main..HEAD

[m4tx]

This is a bit bigger than I originally anticipated. I'm wondering if we actually need to implement the entire instruction decoding functionality - I originally planned that maybe we could just get away with a generic data abort handler and leave the implementation of any specific behavior to the users of the project. On the other hand, perhaps most of them would end up implementing the same stuff anyway - unless there's some way to achieve data reads/writes for the guest easier somehow.

Because this touches way more aarch64 aspects than I'm comfortable reviewing, let's also see what @qwandor thinks.

[zhangxp1998]

Pushed an update addressing the comments:

• align_up_to_page now uses next_multiple_of, and the helper names are now to_pages / to_ipa.
• Moved the syndrome decode entry point to DecodedMemoryAccess::from_register_state.
• Removed the per-data-abort Stage2Config lock by keeping only the IdMap behind a mutex; handler lookup is read-only after initialization.
• When injecting an unhandled data abort back to EL1, ESR_EL1 now rewrites EC 0x24 (lower EL) to 0x25 (same EL).

On the broader scope question: the current emulation remains syndrome-only, not a full trapped-instruction decoder. If the CPU does not provide a valid GPR-transfer syndrome (ISV), we fall through to the normal guest Data Abort injection path. I left full writeback/SIMD support as part of the larger design question for @qwandor rather than expanding this PR further.

Locally re-ran cargo fmt --all -- --check, git diff --check, make build PLATFORM=qemu, make clippy PLATFORM=qemu, and make test PLATFORM=qemu.

[m4tx]

Looks reasonable to me except two last nitpicks.

I can't find any obvious flaws, but as mentioned earlier, I'm not comfortable reviewing aarch64 internals used in this PR. Let's see what @qwandor says before merging this.