3.2.2.2. "rTIL" chunks

this subchunk describes the tiles that make up the region. it's stored
in a compact rle-ish representation.

conceptually, a region is some subset of the 1024x1024 tiles in the map.
to encode a region, encode it row by row, left to right, top to bottom.

for each row, split it into runs of empty tiles and present tiles. for
each run, output one of these bit sequences:

    000nnnnn          - n+1 (1-32) empty tiles in a row
    001000nn nnnnnnnn - n+1 (1-1024) empty tiles in a row
    010nnnnn          - n+1 (1-32) present tiles in a row
    011000nn nnnnnnnn - n+1 (1-1024) present tiles in a row

for the two-byte sequences, the bits in the second byte are the low
bits, and the two bits at the end of the first byte are the high bits.

for example, if you have a run of 10 present tiles, you'd output the
byte 01001001, or 73 decimal. if you have a run of 300 empty tiles,
you'd output 00100001 00101011, or 33 43.

for each row, you must output a sequence of runs that sum to exactly
1024 tiles. anything else (missing tiles at the end of a row, or a run
that extends past the end of the line) is an error.

there are two exceptions to the above rule: first, rows that contain no
tiles at all can (optionally) be encoded specially:

    100nnnnn          - n+1 (1-32) rows of all empty
    101000nn nnnnnnnn - n+1 (1-1024) rows of all empty

second, if the same pattern of tiles appears in more than one
consecutive row, you can use these special codes to save more space:

    110nnnnn          - repeat last row n+1 (1-32) times
    111000nn nnnnnnnn - repeat last row n+1 (1-1024) times

the rTIL chunk must describe exactly 1024 rows. this might require only
two bytes (163 255 for the totally empty region), or it might require
much more.

note: several bit patterns don't correspond to any of the above codings.
that's deliberate. don't use them.