Chunked plant data - to be discussed before merging

This change drops the storage of individual plants in the database, instead storing them as blocks of Java serialised data per chunk. In transactional land this would be bad practice, but we're already saving and loading in a chunk-oriented manner.

Upsides of this method:

  * Much smaller number of rows expected / possible.
  * Many fewer queries (at most 2) to load or unload a chunk.

Downsides of this method:

  * Cannot directly manipulate plant data with SQL queries - have to go via serialisation code.
  * Serialisation could theoretically be wrong - have to deal with invalid data gracefully. This risk is mitigated by sqlite's atomic storage - will not store half - finished data. Unreadable data will result in the chunk's crops not growing until replanted.

If released, this will ignore any existing plant data in the old format (plants table). It will store all plants as entries in the new plant_data table as Java Serialised data. Existing crops would not grow until replanted.