Remove all obsolete GFM quirks handling

[revin]

I can scarcely believe what I'm seeing, but since GitHub now appears to be doing CommonMark compatible parsing, that means we need to remove all of the customizations we so painstakingly assembled over the past few years 😳

CommonMark-compatible processing sometimes results in drastically different output, so I would think GH might be using different renderers depending on when a README was last pushed; however, I haven't checked into this at all.

The first attempt at this PR here just removes all non-CommonMark parsing rules and their tests. Is this what we want? Or do we want the flexibility to render with old-style GitHub rendering (in which case, we'd want to keep everything, but hide it behind an option)?

Fixes #393.

[revin]

Turns out this fixes #390, which is nice.

The main thing that gives me pause here is that I don't have any definite confirmation that the new CommonMark behaviors I'm seeing are permanent. GH's post from a few months ago suggested that this day would come, but I don't know if I can be sure this is forever yet.

[bcoe]

@revin did you come to any decision on this issue? I'm almost tempted to keep our exiting behavior until it collides with future work we're doing, then we can take a step back and decide whether it's worth keeping custom behavior (if it has now deviated from GitHub's parser).

[revin]

@bcoe Well, we do have an open issue now (#390, as above) that's a direct result of GFM getting back in line with CommonMark, so our custom parsing/rendering behaviors are pretty surely unnecessary right now (and since they deviate from GFM, we traditionally consider that a bug on our side). We'll still be wanting to do marky-specific things like rewriting URLs so image references work and things like that, but for actual markdown parsing, I'm all in on being as close to what GFM currently does as possible.