Explicitly include limits.h instead of transitively assuming it

[alerque]

Recent upstream releases of LuaJIT have broken building this Lua Rock entirely. PUC Lua and LuaJIT builds up to a certain point included this header in lua.h, which meant that it was always around as a transitive dependency. Recent upstream LuaJIT builds no longer include the header since they aren't using it directly any more, but that means things that include lua.h don't get it for free any more. It should never have been assumed anyway, but that's been the status quo for a while.

This fixes build errors when using LuaJIT headers instead of PUC Lua:

lutf8lib.c: In function ‘Lutf8_codepoint’:
lutf8lib.c:398:22: error: ‘INT_MAX’ undeclared (first use in this function)
  398 |   if (pose - posi >= INT_MAX)  /* (lua_Integer -> int) overflow? */
      |                      ^~~~~~~
lutf8lib.c:12:1: note: ‘INT_MAX’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’?
   11 | #include "unidata.h"
  +++ |+#include <limits.h>
   12 |
lutf8lib.c:398:22: note: each undeclared identifier is reported only once for each function it appears in
  398 |   if (pose - posi >= INT_MAX)  /* (lua_Integer -> int) overflow? */
      |                      ^~~~~~~

This is because INT_MAX is defined appropriately for a given platfrom in in limits.h.

[sonarqubecloud]

Quality Gate failed

Failed conditions
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[alerque]

Here is an example of a CI build that fails because of this issue. Here is a Homebrew formula where I had to patch this to get a formerly working formula to build again.

[alerque]

The QA analysis above is returning results from code I didn't touch. I don't think it's taking the PR diff into account.

[starwing]

Thanks for contributing!

[alerque]

Thanks for the quick merge! Will there be a release soon so I can start removing workarounds (and stop wasting my time creating new ones!)? This isn't just a case of wanting new things (where possibly using a Git HEAD dependency can make sense) but lots of existing things using stable tagged releases that have worked for years are suddenly breaking.

[starwing]

@alerque done