C++ objects are not destructed if a Lua error occurs

[slipher]

This problem affects both RmlUi Lua and sgame Lua. When a Lua script causes an error (such as trying to index into nil), the Lua interpreter stops execution of the script by calling longjmp. It is possible that there are C++ extension functions in the stack at that point. (For example the LuaPrint function to replace print is a C++ function that can be called from Lua, which in turn may call into a custom __tostring function.) In most C/C++ implementations, stack unwinding is not performed with setjmp/longjmp, so local variables won't be destructed.

The way to fix this is by building Lua as C++ instead of C. When built in this mode, it uses exceptions instead of setjmp/longjmp. Upstream RmlUi supports this using the RMLUI_LUA_BINDINGS_LIBRARY CMake option, which when set to lua_as_cxx defines a RMLUI_LUA_AS_CXX macro. We don't use their cmake so we can just cherry-pick the macro part.

Package managers probably don't provide a C++ version of Lua, so we would need to add it as a submodule. I have a vague recollection of @illwieckz suggesting we vendor Lua for some other reason as well, but I don't remember what it was.

[slipher]

Previously we tried to get rid of C++ exceptions in preparation for a possible move to WebAssembly. Implementing this could undermine that effort. But setjmp/longjmp may not work either, so whatever?

[slipher]

In case we migrate to the "Saigo" NaCl compiler, we won't want to use the Lua C++ mode. Because this toolchain supports setjmp/longjmp, but not exceptions.