[lua] Default to vanilla JSON parser

[jdonaldson]

Summary

• Switch the Lua target's default JSON parser from hx-lua-simdjson (requires native C dependency via luarocks) to the pure Haxe implementation
• hx-lua-simdjson can still be enabled with -D lua_simdjson for users who want the performance
• The lua_vanilla define continues to work as before for disabling all native Lua dependencies

Motivation

hx-lua-simdjson requires compiling and installing a C library via luarocks, which adds friction to the default Lua target experience. For most users, the pure Haxe JSON parser is sufficient, and users who need simdjson's performance can opt in explicitly.

This also makes it easier to treat simdjson as a third-party library rather than a compiler dependency.

Test plan

• CI passes with default (vanilla) JSON parser
• Verify -D lua_simdjson still works when the luarock is installed

[jdonaldson]

I'd like to work on improving some of the Lua FFI behavior, and I realize we're still using an old custom simd json parser. I think we should default to using basic vanilla json here, and only enable that if someone really needs the speed. If we get better FFI support for arbitrary libs, it should be dead simple for them to wrap whatever tool they want (as long as they can access FFI in their env).

Mainly looking for conversation first though, that library was one of the last things I worked on before I left, and it didn't feel particularly elegant.

[tobil4sk]

Not long ago I did some upstream lua-simdjson work and updated hx-lua-simdjson, so I think it wouldn't be considered "old" anymore. Since we started using it, it now has good windows support and also works on arm64 mac/linux. Current repo is here:
https://github.com/HaxeFoundation/hx-lua-simdjson

However, I think it's fair to have a conversation about this. I would assume it was added mainly to improve benchmark results: #9622. Maybe that does not justify having an additional external dependency that most users could get by without, so perhaps making it opt-in is a sensible idea. Perhaps it is also worth considering whether it should even be part of the haxe std, it could equally be an external library that shadows the std Json type.

[jdonaldson]

I'm also in favor of spinning it off entirely. Keeping simdjson in std was a mistake on my part — it adds a hard native dependency for something most users don't need.

Related thought: would it make sense to have a general "performance-enhanced" haxelib for Lua that bundles native-backed alternatives? Things like simdjson, potentially native regex, etc. — opt-in replacements that shadow std types when you want speed. That way the std stays clean and dependency-free, but there's a clear path for users who need native performance.

[jdonaldson]

I can merge this in, but I think we probably ought to have a haxelib with FFI wrappers for common "web oriented" tasks. Not sure what else should go in there though...

[tobil4sk]

Yes, I think it would be nice to have the haxelib ready first. For now, I guess it can just be hx-lua-simdjson and then we can build a more general haxelib on top of that if needed. It would be nice if there was a more fine-grained way of overriding the json implementation without shadowing the entire file, otherwise it becomes an issue of syncing that file when haxe versions change. I guess maybe we could do some magic with a build macro.