feat: arm64 support

[dsh0416]

A very early stage in dev arm64 support to impl #57

Summary

This PR adds full ARM64 support for both Linux and macOS (Apple Silicon), making retour a truly cross-platform detouring library.

Changes

New Architecture Support

• Added src/arch/arm64/ module with ARM64-specific implementations:
  • patcher.rs - Function patching using 16-byte absolute jumps (LDR X16 + BR X16)
  • trampoline.rs - Trampoline generation with PC-relative instruction handling (ADR, ADRP, LDR literal)
  • thunk.rs - Code generation for jumps, calls, and conditional branches
  • meta.rs - Architecture constants (128MB detour range)

Disassembler Migration

• Replaced iced-x86 with capstone for cross-platform disassembly
• Added src/arch/disasm/ abstraction layer supporting x86, x86_64, and ARM64
• Unified instruction analysis interface via OwnedInsn

macOS ARM64 W^X Compliance

• JIT memory allocated with MAP_JIT flag
• Write access controlled via pthread_jit_write_protect_np()
• Code patching uses mach_vm_protect with VM_PROT_COPY
• Patching routines placed in dedicated 16KB-aligned __TEXT,__detour_patch section to avoid executing from pages being modified

CI Updates

• Added aarch64-unknown-linux-gnu target (native ARM64 runner)
• Added aarch64-apple-darwin target (macOS ARM64)

Code Quality

• Fixed all clippy warnings
• Added # Safety documentation to unsafe functions
• MSRV-compatible changes (1.60.0)

Breaking Changes

None - public API unchanged.

Platform Notes

On macOS ARM64, due to strict W^X enforcement:

• Trampolines require MAP_JIT (may need JIT entitlement for hardened runtime apps)
• Patching temporarily removes execute permission from target pages
• Custom linker scripts should preserve __TEXT,__detour_patch section

[Hpmason]

Thanks for taking the time and looking into implementing this, I know it's not an easy task. There's some changes I'll need you to make before I can really consider a full review of this though.

As far as disassembler, we obviously need a new disassembler to support arm64, but if there doesn't exist a pure rust one that supports arm, we still need to keep iced-x86 for x86. I don't love splitting dependencies, but this library already has some inherit unsafety due to the nature of what it's doing. I don't want to introduce FFI layers that don't have rust's safety guarantees. We swapped out udis with iced-x86 for a similar reason in #41. So keep x86 using iced-x86 and you can still use capstone if there's no good arm64 disassembly rust libraries to handle it (one day we'll hopefully have a more developed library out there to replace capstone with, like we did iced-x86)

Also, keep changes unrelated to arm64 support to a minimum. There are large code diffs just for adding support, so all the extra warning changes updates and style changes makes a big diff bigger and harder for me to review. If this was a small change, I'd be a lot more open to little warning fixes.

I don't have a whole lot of time to look into some of the more specific implementation details, but I'll try to look at it when I can.

[dsh0416]

Understood, I would try to refactor the PR to a minimum.