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
I think this will cause make to re-build the tailor file every time.  Since you said the tailor building process takes some time, we probably want to make sure this isn't re-done every build. 

What you want to do instead is have the target be the `tailors.json` file so that make has an output file to compare mtimes against and know it doesn't need to do any work if nothing's changed. 

Also, using the directory as the dependency like this might also cause a problem: the mtime of the directory will only change if a direct child is created or removed; adding an image to a subdirectory would not trigger a rebuild. Listing the individual files with `find` would probably do the trick.  

Putting it all together, I *think* the following would work:

```make
static: $(TAILOR_OUTPUT)

$(TAILOR_OUTPUT): $(shell find $(SNOOVATAR_SOURCE_DIR) -type f)
    python scripts/write_tailor_config.py $(SNOOVATAR_SOURCE_DIR) $@
```