Figure out how to expose metadata interfaces without exposing implementation

[Ortham]

The API's handling of metadata structures is not ideal, because extending them with new fields is not a breaking change for the YAML metadata but is a breaking change for the API.

One option is to hide implementation detail using the pimpl pattern, another is to only expose metadata in serialised form and providing a schema to define the serialisation.

While the metadata is written in YAML because it's a good format for humans writing structured data, it's a relatively poor format for data transfer. There are also few if any good YAML schema parsers. I'm currently evaluating the following:

• JSON: it's pretty much everywhere, simple and has a schema language that's on the way to being standardised. However, there doesn't seem to be anything for C++ that will generate code given a schema.
• Protocol Buffers: it's pretty heavyweight compared to FlatBuffers, with no obvious advantages for LOOT's use case.
• FlatBuffers: it seems mature, has official implementations in C++, JavaScript and Python, and its schemas can be used to generate code to de/serialise an efficient binary format (and JSON in C++). It's also apparently possible to generate JSON schemas from FlatBuffer schemas.
• Cap'n Proto: It's very like FlatBuffers, but its only official implementation is C++, and its most recent release was v0.6 after two and a half years, so it seems like not as good a bet. It also includes an RPC implementation, which isn't necessary for LOOT.

[Ortham]

Its worth noting that the only methods that aren't constructors or simple field getters/setters that are exposed by the metadata classes and actually used in LOOT are:

• Message::ToSimpleMessage()
• PluginMetadata::GetSimpleMessages()
• PluginMetadata::HasNameOnly()

So having those classes is almost completely unnecessary, the above could easily be free functions.

[Ortham]

The YAML de/serialisation headers are no longer available in the include directory, as of 4fc75979ec0d1cf68e635cae138d91ae96a96c6e, as LOOT now uses independent JSON de/serialisation code.

FlatBuffers and Cap'n Proto turned out to be unsuitable as their classes don't own the data they deserialise, so they're not useful for storing an internal representation. Protocol Buffers doesn't have this problem, but is a very large dependency.

At this point it looks like serialisation as an interface in general is unsuitable as it just makes using the API more difficult for clients.

[Ortham]

After further thought I'm not going to go ahead with pimpl-ing the API's metadata classes, because every metadata syntax update so far has involved breaking changes anyway, and it's not worth me doing the work now for a hypothetical improvement in a scenario that may never occur, I might as well solve the problem when it comes up.