Add option to write front matter in TOML or JSON format

[verythorough]

- Do you want to request a feature or report a bug?
Feature

- What is the current behavior?
Thanks to the work done in #348, the CMS can read TOML and JSON front matter, but there's no option to generate front matter in anything other than YAML.

- What is the desired behavior?
I think ideally we'd have a per-collection front_matter_format option that defaults to YAML, but also allows TOML and JSON as supported formats.

[tech4him1]

@verythorough @erquhart Do you think that front_matter_format should be defined for parsing as well, instead of just trying to infer the front-matter format like we do right now?

So by default, we would always try to parse front-matter as YAML, instead of trying to infer it like we do right now. The benefit of this is that we are not always relying on inferring, so we would be able to support other formats with much less overhead in the future. The downside is that this could be a breaking change for some people: they would have to set front_matter_format before they could read their TOML front-matter again, but then they would get a benefit -- they could write it as well.

[Benaiah]

@tech4him1 I like that suggestion - I'd rather default to YAML and allow other settings than try to infer everything.

[tech4him1]

So for a TOML parser, it seems the most used one is https://github.com/BinaryMuse/toml-node. The problem is that it is only a parser, it doesn't have any output capability. Looking at the TOML spec (https://github.com/toml-lang/toml#v040-compliant) it looks like there are a few other v0.4.0-compliant implementations for JS. This one seems to be the only one that has a parser and dumper, though: https://github.com/jakwings/toml-j0.4, https://github.com/jakwings/tomlify-j0.4. I wonder if we should just switch to it for both parsing and dumping, so we don't have to worry about conflicting implementations (i.e. we could read something but not write it).

[erquhart]

@tech4him1 can you confirm if we're now writing frontmatter in the same language we're parsing? Could have sworn we merged a PR for that, can't recall.

[tech4him1]

@erquhart If you are talking about my last comment above, yes, that was changed in a0b220e.

This main issue is still separate, though.

[erquhart]

Ah right, this is about the format-frontmatter config option that we need to add. Got it.

[tech4him1]

The downside of supporting multiple frontmatter formats in this way:

format: toml-frontmatter

instead of

format: frontmatter
frontmatterFormat:
  name: toml
  delims: "~~~"

is that the user cannot specify any custom delimiters. @erquhart @biilmann Is this something we need to consider now? or do you want me to just go with the first method?

[erquhart]

We could do frontmatter_delimiter: "~~~".