Lua file location debug frame work2

This reintroduces a *nix installer to put the Lua files outside of a direct sub-directory of the Mudlet executable as would be the case on a *nix system (the former would go into say /usr/share/mudlet/lua and the latter in /usr/bin).

Following Vadim's previous request on this a developer can override the (per user) setting that tell Mudlet where to get the Lua files from by setting a control put inside the runtime developer control framework (well mainly a set of organised comments set in the required parts of the code base with a bit of code) - this forces the use of the Lua files from the source directory where the executable was compiled.

For the safety of end-users, so they can't break their binary installation _without_  the source files {and because it gets around a problem I found with the \_\_FILE\_\_ pre-processor macro/variable/something(?) not being an absolute pathfile}, a header file is written (when the qmake or cmake project file are parsed) to the same directory where those source files are and if it is not found the control will not be enabled.

I had to redo some parts of the project files and I tried to take on board recent changes to compiler flags by @ahmedcharles but I don't know that I got them all.  The way that the Lua files were put into the mac bundle in the old mac_src.pro with a wild-card clashed with the way the unix installer wants each file individually listed, I think I have redone the mac stuff so that the individual files are pulled in but this only covers the files exactly needed to run Mudlet and not any documentation or other files.  CMake does support Mac bundles separately from the qtdeploy system so it might be possible to upgrade the cmake project files to built the Mac version.

I can now build AND install Mudlet for a Linux system with Qt using either the qmake src.pro project file or the CMake CMakeLists.txt project file(s).  Whilst the CMake was I believe originally being used just for Windows MSVC building, I suspect that with some tweaking we could build all three main OS system executables.

AT THIS STAGE I THINK FURTHER WORK IS REQUIRED FOR MAC/WINDOWS, other developer's code annotations would be welcome, before an actual merge is attempted.
 
It wasn't clear where we wanted the current directory to be on start-up, originally I though the location of the executable but that may not be a writeable location in the file system for some systems (*nixes and possibly later Windows) so I decided to set it to the profile home directory.  Is there any reason to believe that this may not be backwardly compatible?

As this method is now utf-8 safe it might even work for some non-US Windows users who's home directory contains non-ASCII characters - though there is much more work to do to make even the user Lua <-> Mudlet C++ interface utf-8 transparent.