Safer handling of the Lua stack

[guidanoli]

Some places don't lock the LuaRuntime before fiddling with the Lua stack, and many places don't ensure extra slots either.
This PR also involves other changes:

• Add preconditions and postconditions to important functions/methods
• Change behaviour _LuaObject.__str__
  • If __tostring doesn't exist, use _LuaObject.__repr__
  • If __tostring returns non-string value, raise a TypeError
  • If __tostring raises an error, raise a LuaError
• lua_pushglobaltable instead of pushing _G, which may not point to the global table.
• Make lock_runtime return boolean and not raise error directly
• Use LUA_NOREF and LUA_REFNIL constants for effective handling of Lua references
• Add important assertions (checks if LuaRuntime._state is not NULL, and if _LuaObject._runtime is None, etc...)

[guidanoli]

Can you review this, @scoder ?

[scoder]

Did you test if this has any performance impact? (I.e., can you prove that it doesn't?)

[guidanoli]

Did you test if this has any performance impact? (I.e., can you prove that it doesn't?)

Previously, with the context handler it was 50% the speed.
Now we use inline functions getstacktop and setstacktop, which is now 94% the speed, which I think it's pretty acceptable since the gains in readability and maintainability are greater.

[guidanoli]

Note that getstacktop unlocks the runtime if check_lua_stack raises an error, which is quite important. Otherwise, this resource would not be properly released.

[guidanoli]

I change my mind -- I think it's fine the way it is, explicit and efficient.
However, I still check for extra stack space wherever needed.

[guidanoli]

Could you review this, @scoder? It makes Lupa more reliable, in that we guarantee we can push new values to the Lua stack.

[scoder]

Yes, this looks very clean and helpful.

[guidanoli]

Let's get this merged, @scoder ? I depend on it for future PRs.

[scoder]

Works for me. Thanks!