cfg, cmd: major reorganization

* `--lua-dir` flag, specifying a prefix for the Lua installation to
  be used. This reconfigures LuaRocks entirely, including allowing
  a LuaRocks which is itself running using one Lua 5.x version to
  manage packages for a different Lua 5.y version. The resulting
  configuration can be checked with `luarocks config --lua-dir=<path>`.
* requiring `luarocks.core.cfg` no longer has side-effects
  * configuration now needs to be initialized with `cfg.init([lua_data])`,
    where `lua_data` is a table with the configuration of the VM:
    * `lua_version` - e.g. `"5.3"`
    * `luajit_version` - e.g. `"2.1.0-beta3"`
    * `lua_interpreter` - e.g. `"lua5.3"`
    * `lua_bindir` - e.g. `"/usr/local/bin"`
    * `lua_libdir` - e.g. `"/usr/local/lib"`
    * `lua_incdir` - e.g. `"/usr/local/include/lua-5.3"`
  * `cfg.init` can be called multiple times, reconfiguring the global state.
    This is important since `luarocks.loader` now calls it, and the `--lua-dir`
    command line can override the configuration and reconfigure LuaRocks.
* `site_config_*` is no more: LuaRocks is no longer dependent on a properly-written
  site_config file. Instead, it can *optionally* use `luarocks.core.hardcoded`
  for hardcoded values, or detect its configuration at runtime, based on
  OS detection, arg[-1] or command-line flags.
* reduction of moving parts in the configuration:
  * `cfg.platforms` is no longer a globally-visible table; instead, `cfg`
    provides an API of read-only functions: `is_platform`, `each_platform`,
    `print_platforms`.
  * `cfg.*_proxy` options are no longer configured via the config files,
    but rather via the standard `*_proxy` environment variables.
* `"windows"` is now the more general platform name of the Windows family.
  This is technically a breaking change but I don't expect it to cause
  problems with real-world rockspecs.
* internal code reorganization in `luarocks.cmd` module

0 files changed, 0 insertions, 0 deletions