Add Snoovatars.

Snoovatars feature for gold user.  Design/concept and prototype by @powerlanguage, backend by @spladug.  Currently looks like this:

![screen shot 2014-10-20 at 5 00 11 pm](https://cloud.githubusercontent.com/assets/2260961/4711136/4e204472-58b5-11e4-996e-b43cbf050dd5.png)

This feature allows gold users to create a custom "snoovatar".  Users can choose to make their creations publicly available via the `/user/<username>/snoo` URL.

- - - - -

## frontend
Since the js is pretty one-off, I added way more comments than we normally do.  `snoovatars.js` is structured thusly:

1. **init code** – top half of the file, all of the init code is done via [jQuery Promises](http://api.jquery.com/jQuery.Deferred/).  The general flow is:
    * `tailors.json` and existing snoovatar data are passed in from the template
    * spritesheet images defined in `tailors.json` are preloaded
    * when the images are ready, `Tailor` objects are created to manage each configurable part of the snoovatar
    * a `Haberdashery` object is instantiated to manage the tailors and overall state of the snoovatar widget
    * canvas elements and dynamic UI elements are generated and added to the DOM,
    * a generic `view` object is created and event handlers are bound to hook up UI elements to methods of the `Haberdashery`

2. **"classes"** — bottom half of the file, defines a couple of one-off object types used to manage the widget:
    * `CanvasArray` contains shared code between `Tailor` and `Haberdashery` types (basically, having a canvas property and an array of things).
    * `Tailor` manages a single category of things that users can customize about their snoovatar (e.g. hats, glasses, etc.).
    * `Haberdashery` manages state, handles importing and exporting data, and renders the composite snoovatar from the configured `Tailor` objects.

## backend
the configured snoovatar is stored as a blob of json, so the backend is pretty simple.  @spladug, the only thing I changes (i think) is that I ended up wanting to store `key:value` pairs rather than just an array of `value`s, so I swapped out the `VPrintable` validator with `VJSON`, which seems to work fine.

## design/art assets
Design, spritesheet images, and data in `tailors.json` is likely to change, as @powerlanguage is still working on some of those assets and getting feedback from the design mailing list.  Feel free to comment, though.  I tried to keep the structure of `tailors.json` flexible, and derive as much of the UI from it as possible to minimize the need to edit the code when making simple updates in the future (e.g. adding new graphics).

:eyeglasses: @powerlanguage @spladug @Deimos
the makefile looks great to me. since you've hooked into `static` this will automatically get built during the static build process. however, i don't think the generated `tailors.json` will get deployed to any servers because statics aren't built on each app and aren't copied out to apps.

i think there are a few options here, the two that come to mind quickest are:

1. don't attach to the `static` build target, the makefile then becomes a thing you run manually and check the results in to git. by tailors.json being in git, it'd automatically get deployed to apps. putting built artifacts into git is pretty bad practice though.
2. emulate how `names.json` is deployed. this would mean a little bit of puppet to set up a symlink on the deploy server and an addition the the `deploy.py` script in private. this is more work but i think more correct. (this will eventually be less of a problem when we start building packages for deployment rather than using git)