Revamp/improve building of Lua module

[wkozaczuk]

The current build process of the lua module is pretty brittle. It still works on Ubuntu 20.10 but not on modern Fedora 33 (possibly 34 as well) - for details see this conversation on the mailing list.

To add some context, originally we used to build Lua and LuaRocks from sources that had its own disadvantages - long build time and a new version of GCC would eventually require us to upgrade the lua makefiles and would be a massive effort. So my patch changed the build process to mostly use lua from host. But this came with its own problems which Fedora 33 started exhibiting. In essence new Fedora comes with Lua 5.3 and 5.4 (or the latter) and our lua module makefile can only deal with 5.2 and 5.3. Somehow forcing to use 5.3 of Fedora does not seem to work.

The extra problem is that our lua module (through cli) pulls other lua libraries like lua-socket which are also tied to a specific lua version. On top of that the lua source files in cli may simply break with a newer version of lua as some of it API changes (or maybe the lua libraries change).

So I think we have two options:

1. Somehow fix the current building from the host and make it use 5.3 on Fedora. Will future versions of Fedora and Ubuntu provide version 5.3? For how long? Currently, the setup.py simply installs lua for Fedora so who knows what we get?
2. Change the process to download pre-built libraries from the web. It seems that this link - http://luabinaries.sourceforge.net/ (and for example this - https://sourceforge.net/projects/luabinaries/files/5.3.6/Linux%20Libraries/) provides pre-built lua .so, .a and header files. That way we can always have a specific version of lua. The only problems might be the lua libraries (like LuaSocket) that depend on some shared libraries.

[wkozaczuk]

This bug actually causes the default image build - scripts/build - to fail on Fedora >= 33 as it defaults to cli which depends on lua.

[nyh]

Another option, which we use for other modules, is to download an old package from some distro that keeps ancient versions around (e.g., Fedora), open that, and use the executable from there.
The problem with this approach is that eventually it will stop working (if it didn't already...) because of #821...