This commit partly reinstates changes from 5465d6f that had been somehow
reverted in 17d3eb2.  Also, a comment has been added in the hope that future
changes won't do the same.

Additionally, refactor the LUA_PATH env var to ensure that the internal lgi lua
files can't be required explicitly and to avoid possible name clashes (this
fixes issue #60232).

Finally, rather than using prepending `?.lua` append `;;` to LUA_PATH. Quoting
@psychon:

> This is interpreted by Lua as "add the default search path here" (which does
> indeed contain ?.lua, but also contains more).

Testing done:

- Build with `nix-build -I /path/to/repo -A awesome`
- Start an X session with xterm only
- Start xephyr, e.g. `Xephyr :1 -name xephyr -screen 512x384 -ac -br -noreset &`
- Run awesome like `DISPLAY=:1.0 ./result/bin/awesome`. Additionally, add
  `--search` options to expose lua modules that have a name clash with lgi's
  internal ones (see #60232 for more details) and `require` them in `rc.lua` to
  prove that they are loaded correctly

Using wrapProgram makes so that the generated "awesome" wrapper duplicates its
command line options at every restart.

As @psychon puts it:

> AwesomeWM restarts via execvp(argv[0], argv). In NixOS, wrapProgram is used
> to generate a wrapper around the real binary. wrapProgram calls makeWrapper
> with --argv0 '$0'. I guess this is what makes awesomeWM run the wrapper again
> on restart. Without this --argv0 awesomeWM would directly restart itself
> instead of the wrapper, I think.

(cherry picked from commit 88f84c0)

(cherry picked from commit cf5ed1d)

awesome: refactor LUA_PATH env var and don't expose it at runtime (19.03 branch)