Run code from ROM patch 1/5 -- ZIO "direct mode"

This patch series is derived from some of the work done on eLua. Specifically,
this set of patches is derived from
https://github.com/elua/elua/commit/d54659b5723bcd2b1e3900362398c72c18a9aa0b.

This commit changes lzio to handle a "direct mode" where it does not actually
buffer and read data but instead directly exposes the backing pointer (which
is most likely pointing into ROM). Note that this patch does not cover all
use cases of lzio (specifically what is needed for the lexer/parser) and only
can handle the use cases in lundump.
Run code from ROM patch 2/5 -- Align function/debug data

This patch makes function opcodes and debug linenumber information aligned
to 4 bytes. This is much more efficient to load on most 32-bit platforms.

This is ABI INCOMPATIBLE with existing bytecode files. Those will need to be
recompiled.
Run code from ROM patch 3/5 -- GC changes for ROM opcodes

This patch contains the necessary changes to not free the opcode data if it
was originally loaded from ROM (and wasn't allocated via the allocater to
begin with).
Run code from ROM patch 4/5 -- Actual ROM chunk support

This patch adds the actual changes in lundump to handle creating a function
Proto that has code pointing to ROM.
Run code from ROM patch 5/5 -- load from ROM API

This patch adds a luaL_loadbufferro function that behaves almost identically
to luaL_loadbuffer except that it expects a pointer to ROM.
Begin reworking ROM logic into a checkxip function

This function is supposed to return true iff the buffer passed in is in ROM
or otherwise can be treated as immutable to Lua. All the APIs that the eLua
patches touch are being modified to automatically call checkxip rather than
having various special variants for XIP.
Implement eLua pseudo-RO strings

These strings contain the actual string bytes in ROM. However, the TString
object is still stored in RAM and contains a pointer to the ROM data where
the string bytes would normally live. Note that if a pseudo-RO string gets
GC'd and recreated, it most likely will no longer be a pseudo-RO string.