Add option to store bin tileset and map data as JSON

Description

Motivation

Binary data in version control gets added as blob data, as opposed to say a text file which you can derive changes from. By adding a text file this makes version control much more useful in knowing what changed version to version and makes merges much more resolvable at a granular level.
By having text files, in this case JSON, you can add additional information at the top level for the binary data. This information can include things such as how to serialize the data and other information on how to use the data. Data headers are pretty normal and it allows us to do more things with it.
Additionally by having a data header to describe the bin data, this allows the bin data to have varying ways of being serialized/de-serialized for example in the case of supporting both FRLG and RSE metatiles.
Issues can occur with a binary blob that are difficult to resolve. By having a higher level text file to regenerate the bin data, you can ensure the data is more resilient to issues
Lastly, you can change the data format and ordering much more readily as each variable is stored as a single value as opposed to packed, and then you can compile by a collection bitmasks to pack the data as you want it.

Implementation Details

Each one of these json objects should describe how to serialize and de-serialize it.
We can add additional information that can change from the "global" format.
The bin data won't be going anywhere, it's still used in the actual c code.
The json should get compiled as part of the makefile.
The bin data should get ignored by git because we can regenerate it.
For metatiles, there should be a flag set for using json with the metatiles.
~~For layouts, the json should be able to specify if you're using a bin or json file, and if it's a json file, compile it. This will involve updating the mapjson tool~~
For layouts, there should be a flag to set for using json with the mapdata.

Implementation Details - Layout Mapgrid data

The layouts directory has data at: data/layouts/<map>/(border|map).json

The data gets packed as a 16-bit number in the bin. So we store the size in bits (in case the user wants to change this), masks for each variable for the packed data which makes up the "header" data for the map and border. We then store the mapgrid data which is an array of mapgrid items that consist of a collection of variables needed that should correlate to the masks. Something to note is you can have more variables than is in the mask, this is by design, so only the data in the masks will make it into the packed variable.

{
  "mapgridSizeInBits": 16,
  "mapgridMasks": {
    "metatileId": "0x03ff",
    "collision": "0x0c00",
    "elevation": "0xf000"
  },
  "mapgrid": [
    {
      "metatileId": 520,
      "collision": 1,
      "elevation": 0
    },
    ...
  ]
}

Implementation Details - Tileset Metatile Attributes

Similarly to the tileset mapgrid data, we want to store a "header" of higher level information to describe the actual binary data. We store the size of the variable, the number of metatiles in the binary blob, and again the masks for the attribute data. It's important we store the num of metatiles because in FR/LG, RSE they have different num of primary and secondary tiles. This design can support any arbitrary combination of these tile numbers as long as you code it into the c code to deserialize it properly.

{
  "numMetatiles": 512,
  "attributeSizeInBits": 16,
  "attributeMasks": {
    "behavior": "0x000000ff",
    "terrainType": "0x00000000",
    "encounterType": "0x00000000",
    "layerType": "0x0000f000",
    "unused": "0x00000f00"
  },
  "metatiles": [
    {
      "attributes": {
        "behavior": 0,
        "encounterType": 0,
        "layerType": 0,
        "terrainType": 0,
        "unused": 0
      }
    },
    ...
  ]
}

Implementation Details - Tileset Metatiles

Metatiles contain additional information in the header that describe the number of palettes in the tileset because you can have differing number of palettes for example in the case of RSE and FRLG. We also store the number of tiles, which correlate to the tiles in the actual "image". As well as the number of metatiles same as in the metatile attributes. The number of tiles in the metatiles are additionally stored because triple layer and any other arbitrary number of layers of these tiles can be added and specified.

{
  "numMetatiles": 512,
  "numTiles": 512,
  "numPals": 6,
  "numTilesInMetatile": 8,
  "tilesMasks": {
    "palette": "0xf000",
    "tileId": "0x03ff",
    "xflip": "0x0400",
    "yflip": "0x0800"
  },
  "metatiles": [
    {
      "tiles": [
        {
          "tileId": 0,
          "xflip": 0,
          "yflip": 0,
          "palette": 0
        },
        ...
      ]
    }
    ...
  ]
}

Serializer tool

There should be a tool that builds the .bin files from the .json files. This should be called from the makefile to serialize as a step before the .bin files are used. Within the makefile we should add a new variable to enable or disable if you're using json files for the map layout jsons, as well as a variable for if you're using the metatile jsons.

The tool will use nlohmann's json library to pack the data based on the "header" information, using the attributeMasks to pack the data.