Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
It was hardcoding VS 2017, but now uses vswhere.exe to find newer Visual Studio versions too.
Newer versions of VS don't actually support UWP JavaScript, though. However, if users have UWP installed in VS, the error message will be clearer about that lack of support.
Originally, we forced compilation on x86, presumably because at the time HashLink lacked good 64-bit support. When this support improved, the line was changed to force x64 compilation rather than being removed, which may have been a mistake. Now that there are even more valid architectures, it just doesn't make sense to force one.
The old logic could produce inappropriate results, such as attempting to compile an x86 binary on ARM64, or compiling no binary when "64" is specified on a 32-bit machine. I'd argue that it makes sense to only check the flags when they're supported, and not to bother otherwise.
Fixes error: The armv7 architecture is deprecated. You should update your ARCHS build setting to remove the armv7 architecture. (in target 'Build Haxe' from project 'MyProject')
The no-inline macro was added previously to fix a compatibility issue with an older version of Haxe. It remains to be seen whether or not it is necessary as it seems to create conflicts with intermittent versions of Haxe. For this purpose we will remove it, unless it is deemed necessary again in the future. See: https://github.com/openfl/lime/discussions/1645 for more info.
The HashLink executable expects hlboot.dat and libraries to be in the current working directory (it's not enough for them to be in the same directory as the executable). Make the .app file launch a shell script that 1) changes the current working directory 2) launches the HashLink executable
