Allow incremental rebuilding of previews

[harding]

Currently, when previewing a change to the site with make preview, one needs to rebuild every page for each test change. For a rebuild with all optional plugins disabled, this takes 27 seconds on my laptop; for a full rebuild with all plugins enabled, this takes 293 seconds.

This PR changes make preview to use what Jekyll calls "incremental rebuilds" where only pages detected as changing are rebuilt. The time to rebuild varies by what you change---for example, a layout change that affects all pages will take as long as a complete rebuild---but for a single-page change, I find this takes about 7 seconds on my laptop with all optional plugins disabled, although 240 seconds with all plugins enabled.

I think those times could be improved further (on BitcoinCore.org where they don't have homebrew plugins, incremental rebuilds with all plugins enabled take less than a second for a single page change), but I think going from waiting 27 seconds to 7 seconds to preview a change is a major improvement for people who work on editing the site locally.

---

Technical notes: all Bitcoin.org plugins were written for Jekyll 0.5 but we currently use Jekyll 3.0, so three of the plugins had to be changed in order to enable incremental rebuilding.

1. The events and contributors plugins were loaded non-idempotently. Specifically, on the initial load, they each monkey-patch a Jekyll function; on reloads during incremental rebuilds, they attempt to monkey patch the function they already money patched, causing the build process to lock. The first commit fixes this by suppressing the additional monkey patching.

2. The less CSS plugin used to turn nested stylesheets into valid CSS stylesheets deleted its own output on successive runs. This was fine when we always did full rebuilds, but it meant that after an incremental rebuild we had no stylesheets. Instead of fixing the plugin, which was needed when we used Jekyll 0.5, I changed to using SCSS/SASS nested stylesheet support that is included by default in Jekyll 3.0.

   The second commit implements both the previous LESS and new SCSS side-by-side so that the results can be diffed. Here's the diff; I only see whitespace changes. The third commit removes less, and the fourth commit compacts the SCSS output to save bandwidth.

The final commit turns on incremental rebuilding when make preview is run.

Except for the CSS now being more compressed than before, the content of the site should be unchanged. Preview here: http://dg0.dtrt.org/

[crwatkins]

Concept ACK.

[wbnns]

@harding This is great, thanks Dave.

Unless others object, this will be merged on Sunday, June 25th.

[laanwj]

This is awesome. I suppose combined with Travis caching this could also reduce the turn-around time for the checks.

[harding]

@laanwj If we enabled caching, this PR would only reduce Travis time by 10% according to some quick profiling I just did. That's not enough IMO to justify a different testing process than the live site build process.

If I improve the build further, then using caching and incremental rebuilds for both Travis and the live site build would seem warranted. The main goal for this PR is selfish: I've been doing a lot of editing on the dev guide, and I got tired of waiting 27 seconds to see my changes. Just 7 seconds is much better.

In the meantime, I'll see what I can do for the Bitcoin Core binaries URL check that you use. That currently runs about 300 seconds into the full build process, but if I move that check into the releases plugin itself, it'll run about 15 seconds into the full build process---giving you a faster fail in case of problems. (I'll do that in a separate PR.)

[laanwj]

@harding OK, fair enough. Yes my main issue would be that the Travis check turnaround time when adding a new release takes long. This isn't a problem when it's only to be done once, but as we regularly have to fix small HTML/Markdown issues in the release notes this can take a lot of time.