Increase ~16'million extended tile lists limit

[simonpoole]

Currently the tile encoding

`     6                   4                   3     2 2 2
      3                   7                   1     6 4 3
      XXXX XXXX XXXX XXXX YYYY YYYY YYYY YYYY 1uuu uNNE nnnn nnnn nnnn nnnn nnnn nnnn
 
      X - tile number
      Y - tile number
      u - unused
      1 - always set to 1. This ensures that the value can be distinguished from empty positions in an array.
      N - bits indicating immediate "neigbours"
      E - extended "neighbour" list used
      n - bits for "short" neighbour index, in long list mode used as index

limits the number of elements that can have an extended tile list (that is that need to be copied in to more than just nearby tiles) to 2^24-1 (16'777'215). An easy fix for this, that would likely suffice for a while would simply be to rearrange the encoding as

`     6                   4                   332  2
      3                   7                   109  7
      XXXX XXXX XXXX XXXX YYYY YYYY YYYY YYYY 1ENN nnnn nnnn nnnn nnnn nnnn nnnn nnnn

As the NN bits are not used when the extended lists are in use (that is when E is set), this gives us an extra 6 bits without having to change the logic at all. This would allow to index 2^30-1 (1'073'741'823) extended tile lists. @tordanik comments?

[simonpoole]

As the NN bits are not used when the extended lists are in use (that is when E is set)

This seems to not be quite true and needs a bit more analysis. (fixed) In the same vein it isn't quite clear why their are two different schemes to mark neighbouring tiles and really it would seem that the NN bits could be completely replaced by the existing 24 bit marker scheme.

[simonpoole]

See #32 (comment)