iphonesim: support iOS simulator builds on Apple Silicon (HXCPP_ARM64)

[AxGord]

Summary

iphonesim-toolchain.xml and finish-setup.xml currently only emit
-arch i386 / -arch x86_64 for iOS simulator builds. On Apple
Silicon Macs (M1/M2/M3) the simulator runs natively at arm64 — there
is no x86_64 simulator slice available unless you launch the
simulator under Rosetta. As a result, OpenFL/Lime native apps cannot
target the iOS simulator on Apple Silicon without an arm64 simulator
build, and the current toolchain does not produce one.

This PR adds first-class HXCPP_ARM64 simulator support:

• Compiler flags use the modern target triple form
  -target arm64-apple-ios${version}-simulator (instead of -arch),
  which is the only correct way to ask clang for an Apple Silicon
  simulator binary — -arch arm64 alone yields a device slice that
  the simulator refuses to load.
• A dedicated .iphonesim-arm64 LIBEXTRA so arm64-sim binaries don't
  collide with x86_64/i386 simulator binaries in LIBEXTRA=.iphonesim*.
• Separate obj/iphonesim*-64/ object directory for arm64-sim so
  parallel builds for different sim slices don't trash each other's
  intermediate objects.
• Linker emits -arch arm64 for the dynamic library on Apple Silicon
  simulator.
• The non-arm64 path (x86_64/i386) is preserved verbatim under
  <section unless="HXCPP_ARM64">, so existing builds on Intel Macs
  and the existing HXCPP_M64 flow are unchanged.

We've been carrying this patch in our soccertutor/hxcpp fork for
~1.5 years, used in production OpenFL+AIR apps that ship to iPad. Built
and tested on Apple Silicon (M1 Pro) against Xcode 15/16 SDKs, iOS
simulator runtimes 16/17/18.

Why the -target triple instead of -arch arm64

-arch arm64 by itself produces a device slice. The simulator looks
at the binary's LC_BUILD_VERSION load command — for arm64 it
expects platform 7 (PLATFORM_IOSSIMULATOR), and clang only sets that
correctly when you ask via -target arm64-apple-ios<x>-simulator.
This is the same approach Xcode itself uses internally for arm64-sim
builds and matches the recommendation in Apple's TN3144 / docs.

Files

toolchain/finish-setup.xml        |  5 +++--
toolchain/iphonesim-toolchain.xml | 36 +++++++++++++++++++++++-------------
2 files changed, 26 insertions(+), 15 deletions(-)

xmllint --noout confirms both files are well-formed.

Use

haxelib run lime build ios -simulator -Dhxcpp_arm64
# or for native HXP / direct hxcpp:
haxe -cp <path> -cpp out -DHXCPP_ARM64 -Diphonesim

The resulting .iphonesim-arm64.dylib loads cleanly on an Apple Silicon
iOS simulator runtime.

Risk

• unless=\"HXCPP_ARM64\" guards on the existing x86_64/i386 sections
  mean the legacy path is byte-identical when HXCPP_ARM64 is unset.
• Verified on the Lime side: with HXCPP_ARM64 unset, iOS simulator
  builds on Intel Macs are unchanged.
• Adds an alternate LIBEXTRA and objdir, so callers that hard-code
  .iphonesim / obj/iphonesim paths need to query LIBEXTRA instead.
  Anything going through haxelib run hxcpp / lime already does.

Context for follow-up

This unblocks an Apple Silicon support PR we have queued for openfl/lime
(NDLL fallback chain, auto-OpenAL backend selection, etc., which depend
on the iOS sim arm64 slice produced by this patch).

Happy to add an entry under docs/Defines.md for HXCPP_ARM64 if
desired — wasn't sure if that flag is documented elsewhere already.