bugfix: src/lj_err.c: rroneous assertion failure on x64 macOS.

bugfix: This PR fixes issue openresty#136 (openresty#144)

and breakage introduced by commit 5980ef9 seen in
kubernetes/ingress-nginx#6504 on s390x.

Additionally implemented:
- Table traversal changes for s390x introduced in commits c6f5ef6 and bb0f241.
- CI (valgrind disabled for s390x because of unimplemented instruction).

Signed-off-by: Artiom Vaskov <[email protected]>

change: Introduce a new macro LUAJIT_TEST_FIXED_ORDER for testing so …

…that lua table would have predictable key iteration order.

feature: enable debuginfo in our luajit build by default.

bugfix: fixed gcc warnings when -DLUAJIT_DISABLE_JIT is specified.

This regression had appeared in commit 29e9e3c.

Merge branch 'v2.1' into v2.1-agentzh

Merge branch 'v2.1' into v2.1-agentzh

bugfix: lua_resetthread: we forgot to reset the "exdata2" field.

bugfix: compilation error "for’ loop initial declarations are only al…

…lowed in C99 mode" would happen with older gcc versions like 4.8.

This regression had appeared in commit 7c03b05.

Adjust SSE4.1 str_hash to replace hash_sparse and hash_dense

The new hashing scheme in luajit is more sophisticated, with two
different hashing functions and a proper multilevel hash to account
for collisions.  The sparse hash function is expected to be fast and
the dense hash function is expected to be slower.  Accommodate the
CRC32 based hash implementation accordingly by splitting it into fast
and slow functions.

The hash_sparse crc32 implementation avoids using the slow 128 and
above path so that it can complement the speed requirements.  Based on
the benchmark it takes about 20% less time to compute hashes compared
to the upstream hash_sparse.  It regresses in the 64-128 byte range
and then again gains performance in the 128 byte and larger range.

The hash_dense implementation is consistently faster than the stock
hash_dense implementation, which scales linearly.  The standard
deviation reported by the tests are comparable for both sparse and
dense implementations.