Better handle lua_tointeger behavior compatible with lua 5.3

[nevkontakte]

Original bug report: https://forums.x-plane.org/index.php?/forums/topic/164744-fwl-ng-278-issues-with-draw_string-functions/

The backstory is that we started using sol2 for better Lua to C++ bindings. As a somewhat unexpected side-effect that brought in lua-compat-5.3 library with it, which changed behavior of lua_tointeger to match that of Lua 5.3:

The Lua value must be an integer, or a number or string convertible to an integer (see §3.4.3); otherwise, lua_tointegerx returns 0.
...
The conversion from float to integer checks whether the float has an exact representation as an integer (that is, the float has an integral value and it is in the range of integer representation). If it does, that representation is the result. Otherwise, the conversion fails.

So the new behavior is to return zero when there is a non-integer number passed when integer is expected. Turns out, our users don't quite expect that :-)

For now I'll implement a quick hack and simply undefine macros which cause unexpected behavior. This is not ideal, so we should consider converging on a consistent approach. Perhaps, accept floats in functions where users might expect them, such as drawing.

I also wonder how sol2 bindings behave in this regard: do they coerce floats to integers always like Lua 5.1 does or it follows 5.3 style. If former, moving to sol2 bindings broadly would be an ideal solution.