Refactor WebAgg so it can communicate over another web server

This is to address an immediate need we have at STScI, but probably needs some explanation.

We want to embed interactive WebAgg plots inside of a larger web application, but we don't necessarily want to serve the matplotlib websocket or http requests using tornado.  We'd like to, instead, allow people to "bring their own webserver framework" to the party and have matplotlib communicate over that. (@stsci-sienkiew).  The requirement for "websockets" specifically is still there.

This refactor should also make it easier to move to IPython's future widget communication pipeline down the road (@ellisonbg).

The easiest way to see how this works is to look at the `embedding_webagg.py` example, which embeds a plot in an example tornado application.  I'm using tornado here for the example, even though that's what the "built-in" matplotlib server uses because it's really the only viable and mature Python tool for websockets I could find.  It still makes for a useful example for how to embed in a larger Tornado application which might be doing many other things.  I plan to write proper "how to" documentation for this, but thought I should hammer down the details first.

As part of this, the Javascript API has all been moved under a single "mpl" namespace, so that it should be easier to import it alongside other Javascript libraries without fear of name clashes.  If anyone is currently using the Javascript API to matplotlib to insert plots on their webpages this will break that.  As this stuff is all still new and marked "experimental", I'd rather just break this now to get that right rather than carry around the baggage of not namespacing things correctly to begin with.

Cc: @pelson, @andreabedini (as people who have helped with and been interested in WebAgg).

@pelson: You may also enjoy that, ignoring the example, this is a "net deletion" pull request.