Better parse fragments.

This is in preparation for actually using fragments. The original plan
was to ask Perl 6 to interpret the fragment as a qww list, which is why
fragments weren't handled much before. However it became real clear that
it would be far easier to do the parsing ourselves :) .
Add grammar & actions for Pod6.

Not full-blown, just enough to redo backlink-adding properly.
Find fragments and insert backlinks.

It works, though some efficiency improvments are imminent.
Stop searching if you reach the next header

This breaks a couple of backlinks, but that's arguably an issue of those
backlinks. Currently broken, at least on moar.
Fix crashing bug

Yes, we have to manually vivify, and yes, we have to bind instead of
assign to do it. Don't ask why assignment fails in this one spot
(whether using autovivification or doing that manually), in specific
conditions.

specs commit 562ef2c and roast commit 4a5a180 were used when the weird
failure was occurring; use those if you can't reproduce these problems
in the future (which occurs during the first can't-find-section backlink
for S02).
Rework Pod6 Parser

Due to the slowness of the first attempt at backlink placing, we're
going this route in hope of something faster. This is just the changes
to Syngen::Pod6. The necessary changes in syngen.p6 are coming up.
Finish fragment placing.

Note that some things may be broken, most notably placing backlinks
whose section was not found.

Takes around 3800s on my machine, hopefully it'll be faster elsewhere
and in the future.
Implement caching.

This dramatically cuts down on the time the script runs if nothing
changes, and may reduce some time if only one repo has changed (e.g., if
there was an update to the synopses but not the tests, then backlinks
shouldn't be re-gen'd.)

Unfortunately, this process currently isn't very smart; it only cares if
*something* has changed in the specs or roast repo, and then redoes
*everything* relevant. This means that the slowest part, HTML
generation, will reoccur for any change. A smarter system would know
much more about how things are connected.

Additionally, the currently used method for figuring out changes (the
commit sha1 and a sha1sum of  git status --porcelain) isn't perfect; if
you make multiple uncommited changes in a way that git status
--porcelain won't notice between uses (e.g. editing foo.t, running
syngen, and editing foo.t again, without ever commiting), that won't be
noticed, and thus the (now potentially outdated) cache will still be
used.