Builtin: Print warnings if SHA256 of files does not match with build

[Desour]

• Adds a list of builtin lua files in cmake. (like in src) (unittest files are not included)
• Generates a cpp file with relative paths and hashes.
• Prints warnings if you try to loadfile (or dofile) a path in builtin (with abs path) if either the file is not in the cmake list or if the hash mismatches.
  Fixes Make builtin check for expected engine version #16318.
• Code cleanup of ScriptApiSecurity::safeLoadFile.
  (And CPCSM files will now have the shebang ignored (but it looks like luajit already does that).)
• (Will also be useful for SSCSM client builtin (check to prevent cheating) and SSCSM server builtin (to find out which files to send).)
• Doesn't work for CPCSM.
• I've decided for warnings and not errors, as I'm worried that otherwise the user might be left without a working main menu (which right now results in a "No future without main menu!" plus abort) and not know what is happening.
• Side effect: The feature to load code from stdin with dofile() and loadfile() (without args) is removed.
  (ContendDB grep had no true positive results.)

To do

This PR is Ready for Review.

TODO:

• Idk how to properly escape paths in cmake. I.e. if a " is in a path, it might split the list. (see github review comment below)
• On macOs there are issues with the file being added to multiple targets. TODO

How to test

• Start and notice how there are no warnings.
• Change a builtin file, e.g. after.lua. Observe the warning.
• Rebuild, and observe that it regenerates the hashes.
• Comment out a file in CMakeLists.txt. Observe the other warning.
• /lua dofile()
• Look into the generated builtin_files.cpp.

[SmallJoker]

Things I don't like about this concept:

1. CMakeLists.txt for Lua files seems cumbersome, especially because we're taking the entire builtin dir when packaging.
2. A 256-bit hash is not needed. Adler-32 or the murmur hash would be A) much faster and B) fit into an integer value.

My approach would be to write a small C++ program that traverses the directory and generates the source file required by the main luanti CMake target.

[Desour]

For clarity, this is not the same as for GenerateVersion, because GenerateVersion rebuilds every time.
(I hope the comments and DEPENDS make this obvious enough for future readers.)

[Desour]

Things I don't like about this concept:

1. `CMakeLists.txt` for Lua files seems cumbersome, especially because we're taking the entire builtin dir when packaging.

My approach would be to write a small C++ program that traverses the directory and generates the source file required by the main luanti CMake target.

CMake has a glob feature, no need to reimplement it in C++. It was already discussed here: #16553 (comment)

2. A 256-bit hash is not needed. Adler-32 or the murmur hash would be A) much faster and B) fit into an integer value.

Sounds like premature optimization to me.
Also, as said I'd like to use it for sscsm client builtin in the future, and there we need secure hashes (otherwise you can add a comment to the file to make the hash match (though at that point, rebuilding might be easier (well, but not if someone makes a small program that does the adjustments for you))).

[Desour]

I think it might also work to pass build/src/builtin_files.cpp here. One should be able to get rid of GenerateBuiltinFilesCpp then. But this seemed cleaner for me.