(broken) Upgrade Jekyll without changing core configuration (except for 'safe')

Expectations:

- Adding `safe: false` will obviate having to carry that symlink patch on Jekyll.
- This shouldn't break anything.
- A diff of the output directories shouldn't be substantially different.

Results:

- I was right about `safe: false` and the now-unnecessary patch. Woo!
- Activerecord 4.x blows up on Ruby 1.8.7 and won't install.
- Our jekyll command in `rake generate` no longer works.
- The format of the `include` option changed, and now issues a deprecation warning.
- The pygments cache plugin is entirely broken, and the site will not generate
  without removing it. (However, the improved pygments pipe handling means this
  only adds 10-15s to the total build time.)
- The sitemap is broken: it now has two full copies of the directory for every page.
  (http://docs.puppetlabs.com/pe/3.0/puppet_overview.html becomes
  http://docs.puppetlabs.com/pe/3.0/pe/3.0/puppet_overview.html)
- When running stock Jekyll 1.1.2, compilation may explode when encountering any
  <name@domain.com> email address links in the site, with a Kramdown error like
  the following:

  Generating...   Conversion error: There was an error converting
  'mcollective/deploy/middleware/activemq.md'.

  /Users/nick/Documents/puppet-docs/vendor/bundle/ruby/1.8/gems/kramdown-1.0.2/lib/kramdown/converter/html.rb:404:in
  `obfuscate': undefined method `encoding' for "mailto":String (NoMethodError)

  I tracked this down: lib/jekyll/core_ext.rb was ill-advisedly adding a bogus
  method to String. I fixed it and submitted a pull request to upstream as
  9ca7f70d70c612e3d590f009bcb9ae64a6aedd78, and cherry-picked it into our Puppet
  Labs-specific branch as 73f344028681d907ccd8e570db21b15ed3d4fa58. My pull was
  accepted, so hopefully we should be fine with stock Jekyll once 1.1.3 comes out.
- Pygments highlighting for Ruby now farts on Namespace::Namespace
  identifiers. This is a bug in Pygments 1.6, which is vendored by pygments.rb. (I
  had been generating the site with 1.5, dunno what Fred has been generating it
  with. The bug is fixed in prerelease builds of Pygments 1.7, so I guess it will
  eventually get fixed if we keep running bundle update from time to time.)
- The Puppet lexer was added to Pygments as of version 1.6! So we should be
  able to highlight Puppet code for real now instead of settling for Ruby.
(broken) Restrict ourselves to ActiveRecord < 4.0

To retain Ruby 1.8.7 compatibility, we have to be pessimistic about
ActiveRecord. 4.x won't install at all.
(broken) Remove pygments cache plugin

Jekyll version mumble mumble something made syntax highlighting much more
efficient by switching to pygments.rb, which apparently runs a single pygments
process and uses an IO object to shove data through it. The upshot is that we
can get rid of the cache plugin and only suffer about a 10-15 second penalty.
(Remember that this plugin originally took about a minute off our build time.)

Oh, and if we don't delete it, the site refuses to build, lol.
(glitchy) Fix broken jekyll command in rakefile

The syntax of the jekyll binary changed, so we have to modify our invocation.
Taking the opportunity to trim out a Dir.chdir call, while we're at it.

As of this commit, the site will build, although the sitemap is glitchy and
useless and we're getting a deprecation warning.
(fine) Update sitemap generator to deal with new `url` semantics for page objects

At some point, they harmonized the contents of the `url` variable in page and
post objects, so the sitemap generator doesn't need to append `@dir` anymore.
Without this patch, the sitemap URLs contained duplicated directories for each
page.

As of this commit, the site generates just fine, assuming our branch includes
the fix for the force_encoding Kramdownpocalypse.
Fix deprecation warning around `include` setting

This should be an array now. Honestly I don't know why we're including
_index.html, that seems stupid, but I'm trying to change as little as possible
at the moment.
Build header ID munger; divorce us from Kramdown-specific behavior, at a cost

Minuses:
- We've nearly doubled the build time, due to the cost of parsing each HTML
  fragment into memory as a DOM tree and iterating over all of the header elements.
- Installing Nokogiri with Bundler is a crapshoot. What NF found was that he had
  to run `sudo bundle update` instead of just `bundle update`; for some reason,
  Nokogiri wouldn't find the native libiconv library it needed (and was finding
  the wrong version of libxml2???) unless you ran the installation with sudo.

Pluses:
- We can now switch Markdown libraries if we want, and it won't break every
  middle-of-page link into our docs. (It may break a few of the odd ones.)
- We might be able to win some time back in the TOC plugin.
Replace janky TOC generator with better TOC generator relying on our header ID builder

We're still taking a nasty performance hit from Nokogiri; this doesn't really
win us anything back.
Replace the slow Nokogiri header ID munger with a faster gsub-based one

Yes, I know, parsing HTML with regular expressions is wrong wrong wrong. It also
chops about 1m40s off our build time. :/
Switch to Redcarpet for Markdown processing

HOLY CROW, that is more than twice as fast for a complete site build. We're
sub-one-minute for the first time in years.

We should also be able to use fenced code blocks with language specifiers now;
that's to be tested in a later commit.

Blemishes: The smartypants implementation doesn't smarten up apostrophes in
contractions, for some reason. That's about it.

We shouldn't need to add Redcarpet to the Gemfile, as Jekyll has adopted it as
the default for new sites and will automatically install an appropriate version
as a dependency. (i.e. it won't try to install redcarpet 3.)
Convert one page to fenced code blocks, to show how it's done
Stop requiring Nokogiri

The speed hit wasn't worth it, and the installation requirements really
weren't worth it.
Stop printing page titles as we generate

This is noisy and the rest of the team probs won't like it. I'll leave it
commented in case it becomes useful for debugging later.
Add comments for future hackers to all these new plugins

And any old ones we're abandoning.