Revamp config code

[azerupi]

This is a rewrite of the configuration code for the TOML configuration push #285
The JSON configuration should remain unchanged, but is deprecated. Unless we want to support both?

The supported TOML format has been changed to the following:

title = "A book about nothing"
description = "A large book that tells no story"
author = "John Doe"
# authors = ["John Doe", "Jane Doe"]   <-- multiple authors
source = "path/to/src"

[output.html]
destination = "path/to/dest"
theme = "path/to/them"
google-analytics = "123456"

I have also added tests for each key, both in TOML and JSON.

The other files that use the configs have only gotten changes necessary to compile and work. But by going through the code for the changes I realised how ugly my code is... 😄 I think changing the rest is out of scope for this PR, but there is a lot of opportunity for clean-ups.

Closes #285, closes #178, closes #240 and improves the test coverage.

[azerupi]

Ok, this PR is ready for review. I have implemented all the things from #285

• Parity between the JSON config and TOML config
• Move and rename dest, src and theme_path to

  source = "path/to/sources"
  
  [output.html]
  destination = "path/to/output"
  theme = "path/to/directory"

• Add a key for an additional custom stylesheet Add CSS without overriding theme #266 Add an empty, but included last, custom.css file #178

  [output.html]
  additional-css = ["path/to/file.css"]

• Add tests for each config key
• Reading the config should not overwrite unspecified keys some values are overwritten by read_config #240
• Document the TOML config

[frewsxcv]

just skimmed this, everything seems fine to me 👌

[frewsxcv]

do we still need these methods?

[azerupi]

get and set author?
No, we can remove them. I would like to remove the other methods as well and provide a better way to access the configuration, but they are too pervasively used throughout the code and a little to ambitious for this PR.

[azerupi]

Thanks! Let's wait to see if Steve wants to have a look before we merge :)

[budziq]

Hi,

I was thinking about removing duplication of fields between MDBook and BookConfig (most likely keep Option<BookConfig> within MDBook) add getters instead of direct field access (most likely also add builder here and there) for https://github.com/azerupi/mdBook/issues/301 but such refactor would clash with this work.

I'll wait until this gets merged and dust settles before making any proposals.

[azerupi]

Oh yes, that would be a good refactor, when making this PR it was pretty painfull to update all the getters everywhere. Actually now I think MDBook should not even provide getters and setters but just have a method to get the config.

It's pretty safe to say that this PR is going to land soon without much changes. I'm just waiting to see if @steveklabnik wants to have a look before we do.

[budziq]

I think MDBook should not even provide getters and setters but just have a method to get the config.

My thoughts exactly :)

[steveklabnik]

It's pretty safe to say that this PR is going to land soon without much changes. I'm just waiting to see if @steveklabnik wants to have a look before we do.

Yup! 👍