More configurable TOML serialization

Right now, the toml serializer generates only top level properties, and inline tables where necessary (i.e. where arrays are used):

abc.foo = 1
abc.bar = 2
abc.xyz = [{foo = 1, bar = 2}]

There are special cases where we could generate normal toml tables. The example above can be expressed as:

[abc]
foo = 1
bar = 2

[[abc.xyz]]
foo = 1
bar = 2

This format will in many cases be more readable. However, there are problems with non-inline tables that prevent us from emitting them in a streaming generator:

• Once a table is started, it is impossible to go back to the parent or root table. If an object has scalar properties that we only see after we started a subtable, we have a problem.
• Array tables only work with arrays of objects. If an array is heterogeneous, but we’ve already started emitting it as an array table, we have a problem.

These problems can only be solved with knowledge of the tree being serialized, and perhaps even by influencing property order so that scalars always come first. However, because I expect serialization to toml to be fairly niche – it is a configuration format meant to be written by humans, after all – it is not worth adding machinery to databind to implement this.

Another question to consider: What even is the best representation of an object? A short inline object may be more readable than starting a new table that includes the entire path to that object.

A possible solution to this problem would be to add API to the TomlGenerator to specifically start a table. One approach would be to create overloads for writeStartObject and writeStartArray that allow forcing generation as a table. If data is then passed that cannot be represented as a table (the bullet points above), we would error. While we’re at it, could also allow emitting comments with additional methods.

We could also inspect annotations on the forValue passed to writeStartObject, though this seems like misuse of that parameter, so not a good idea.

[cowtowncoder]

PRs welcome!

[cowtowncoder]

@sysmat Yes, as I said, PRs welcome. Arguing about usefulness of something does little to implement said feature.