Add way to store additional information in the binary format

[jviereck]

At the point of writing, the binary format can contain only a set of features. Certain information like street name, house numbers, traffic lights need to be added to the binary file as well.

Personally I am not sure what's the best way to store this additional data. As the data belongs to features (e.g. a street name belongs to a street) it might be good to store the information for the object next to the object directly. On the other side, it might be useful to put the additional information separately. E.g. let every tile contain a meta-data section, that contains all the street name, house numbers etc. Having the data in a meta-data section has the following advantages:

1. searching the metadata is easier as not all the features in the binary format need to be traversed. E.g. think about searching for a street, which could result in a simple lookup in the meta-data street-name dictionary
2. a long street is made up of multiple street features that are located in individual tiles. By storing the name only once in a meta-data section, it can then be used for multiple street features at the same time
3. to make the map more responsive, it might be useful to render the main parts of the map (what is there at the moment basically: street, houses, ... without street names etc) first and then in the next runloop the labels and signs. This might be easier to implement by using a meta section in the binary file, although this statement should be confirmed.

Bundling the metadata for multiple tiles together as proposed in 2. has the downside, that not every tile/zoomlevel can be stored independently of the other tiles. This especially has implications on the backend as it needs to know which tiles share the same metadata and should therefore be delivered together.

[fzzzy]

After some discussions yesterday I am currently leaning towards storing the metadata in a different structure. We are going to need a different structure anyway for searching.