Safety-guards for CSM callbacks to abort on a bad implementation
Only run callbacks when the mods are loaded (and with it: builtin)
Duplication checks inside constructors
* [CSM] Don't load the IO library.
* Rename the function to match the Lua API function name and add a missing `const`
* Add a comment to explain some strange code and fix the other issues pointed out by shadowninja.
Implement network communication for channels
* Implement ModChannel manager server side to route incoming messages from clients to other clients
* Add signal handler switch on client & ModChannelMgr on client to handle channels
* Add Lua API bindings + client packet sending + unittests
* Implement server message sending
* Add callback from received message handler to Lua API using registration method
* Modernize source code: last par
* Use empty when needed
* Use emplace_back instead of push_back when needed
* For range-based loops
* Initializers fixes
* constructors, destructors default
* c++ C stl includes
* Load client-side mods into memory before executing them.
This removes the remaining filesystem access that client-sided mods had and it will hopefully make then more secure.
* Lua Virtual filesystem: don't load the files into memory just scan the filenames into memory.
* Fix the issues with backtrace
* fix most of the issues
* fix code style.
* add a comment
This unifies the settings APIs.
This also unifies the sync and async registration APIs, since the async
registration API did not support adding non-functions to the API table.
