Follow CommonMark spec.

[matthid]

Following Issues like #342 this would be a way to follow the spec.

With some tricks and a .tt file this PR adds code which parses the CommonMark spec html file (http://spec.commonmark.org/0.22/) and creates a test case for each example.

Usually I don't publish my work this early but I hope somebody is willing to help here (currently about 100 of the 600 new tests are passing).

I think this will close a lot of the open issues we have regarding markdown parsing.

@tpetricek Do you like the idea of keeping the generation code or should we only keep the tests?
I think it might be a good idea to be able to update to newer versions of the spec if needed.

[tpetricek]

Nice! I do like the idea of automatically generating the tests from the specification so that we can handle potential changes. Too bad that the specification is not in a pretty machine readable format....

I have not used T4 before - does it work on mono too? An alternative would be to use TestCaseSource like in the existing test that compares PHP Markdown parser files. But I guess both will work here.

[matthid]

TestCaseSource is definitely the way to go, thank you for the hint. That's waaaay better :)

[matthid]

Changed the test generation again and now use the official approach to run python to generate a test-validation json file (https://github.com/jgm/CommonMark#running-tests-against-the-spec).
The json file is consumed via the FSharp.Data json provider.
This simplifies the code a bit and gives some more metadata (like section of the spec for the given test).

I have changed FSF in a way to follow the spec for the 'Fenced code blocks' and 'Indented code blocks' sections (all other sections are disabled for now, see https://github.com/tpetricek/FSharp.Formatting/blob/master/tests/FSharp.Markdown.Tests/CommonMarkSpecTest.fs#L20)

It's probably better to merge this now and handle section by section in the future (we may even get contributions for other sections by other people).