Add data property to chapter struct

[bgotink]

This data property makes it possible to share data between pre-processors, or between pre-processors and the renderer, including the "html" renderer which exposes the chapter data as "data" in the .hbs files.

I've explicitly not provided a built-in way to configure data. Any built-in approach for parsing data would have to be discussed. While I consider hugo/jekyll style front-matter pretty standard for this kind of thing, others might disagree. Even if everyone agreed, the question would then become "what flavours of front-matter do we support?"

I've also explicitly not created any data properties that are used out of the box by mdBook itself.

I'm assuming this PR would need to go in 0.5.0, as it changes the JSON model and any pre-processors compiled with older versions of mdBook would strip the property.

For reference, my use case: I have (many) large JSON files containing data, and I want to use a pre-processor to insert the correct data in every chapter, to then use it in our theme's .hbs file to generate a metadata table, links, that kind of stuff.

Related:

• Request for chapter metadata: Metadata on a per-page basis #2142
• Request for TOML front-matter: Allow chapters to have an optional TOML header #277
• Other PR adding a data property to chapters: Create a chapter_config for chapter specific properties to be exposed to the handlebars template. #1465. That PR adds a pre-processor to extrat TOML front-matter, and it defines a few data properties that are built into mdBook. This PR is more limited in scope.
• Crate mdbook_frontmatter which processes a fixed, limited, set of data properties in YAML front-matter

[CakeVR]

Hello, the lack of front matter support in mdBook is unfortunate, and this pull request seems to add great power for preprocessors.
If I were able to parse the front matter of each chapter, I would be able to generate Open Graph Meta Tags per chapter in the index.hbs.
This allows for great link embed previews.

I'm sorry to see your work has not been looked into yet.
I do hope it gets reviewed and evaluated, thanks for your effort.