(- meta fix) Fixing `cake clean` to be properly async
(new meta) Coverage tooling! (And a shit-ton of other stuff.)

This is a fucking mess, too. In so many ways, not controllable by myself. Where to start ...

The `require()` problem™
========================
 - coffeeify (for browserify 2.x) *requires* that every `require()` statement explicitly end with
   the string ".coffee", to grab the file and bundle it into the browserify bundle
 - after instrumenting for coverage, the relevant (*instrumented*) files are `.js` files; thus, all
   of my `require('fuck-me.coffee')` statements will fail within the instrumented code; not to
   mention that the tests themselves also have to directly require the `.coffee` files
 - browserify will only work with `require()` statements for which the first argument is a direct
   string-literal in the source-code; so we can't work around this with the obvious
   complex-expression *in-place*

So, until the whole clusterfuck that is substack/coffeeify#1 is fixed (see also:
shtylman/node-browser-resolve#19, shtylman/node-browser-resolve#20), I've created a shim-file that
*wraps* the local `require` for each file in another function which mangles the name as necessary
based on the coverage environment variables, and then *replace* the local `require` function
in-scope with that wrapper.

Thus (phew), we can:

1. Satisfy browserify 2.x with ASTs of the exact form `require('<string literal>')` (hey, *it*
   doesn't know that the *value* of the `require` token has been re-defined!)
2. Satisfy coffeeify with string-literals ending in `.coffee`
3. Generate coverage for instrumented plain-JavaScript files that actually *resolve* all of their
   requires

Fuck Cake
=========
What the title says.

Node is great for a lot of things, but “rake”-style task management isn't one of them. I briefly
considered simply using Rake, even though I'm in a JavaScript project ... but then I decided to go
with the Node-y UNIX flow, and just resort to shell scripts. I'll be writing them generically (to
function in everything from dash, to bash, up to zsh); the remainder of migration from `Cakefile` to
`Scripts/*.sh` will happen in later commits. For now, though, I completely failed to reasonably
employ the available coverage tools through Node's `child_process` and similar, got fed up, and
immediately implemented both the `npm run-script coverage` and `npm run-script coveralls` as
shell-scripts, and just called out to *those* from the existing Cakefile.

Due to me being lazy in that way, we might have a hybrid Cake and shell-script build system for a
short while. Meh.

Travis-CI and Coveralls.io
==========================
There isn't any *official* support for Node (or JavaScript at all, for that matter) from Coveralls;
there's a third-party library, node-coveralls, but it's absolutely terrible. I've patched it and
pull-requested (see: cainus/node-coveralls#6) to make it reasonably usable for my purposes here;
I've also had to modify some Travis configuration to work with all this. We'll see if it works when
I push this commit.