Returning the sandbox's environment to the sandbox caller gives flexibility to invoke functions defined in the caller's scope but using the sandbox's environment.
This changes envs in three ways:
* They are strict read-only. This minimizes the surface attack if someone with malicious intent overrides global stuff on an environment which happens to be reused.
* Envs can override the base env
* Envs with metatables now use them
The solution we use in PUC Rio Lua (with debug.sethook) simply does not
work in LuaJIT.
* We have added a `sandbox.quota_supported` field to signal this feature
(or lack of thereof)
* We explicitly return an error if `options.quota` is passed on a LuaJIT
environment, in order to prevent LuaJIT users from believing that they
are protected against infinite loops.
This change drops support for "protecting" raw Lua functions.
There are two main reasons for this change:
* More modern versions of PUC Rio Lua don't have `setfenv`. It is
possible to get around this by using the debug library, but that
library is not available in all environments.
* Solutions based on `load` (which only allow string inputs) are
objectively better since they give the user more control. For
instance, you can deactivate support for binary code selectively.
As a result, we are using the `load`-based sandbox in all versions of
Lua that supports it, using `setfenv`-based sandboxing only when nothing
else is available (PUC Rio 5.1).
We are also explicitly raising an error if `options.mode` is passed but
we are using `setfenv`. This is to prevent users from believing they are
protected against binary code, when in fact they are not.
