[WIP for review] Support multiple top-level SVG Workspaces and Toolboxes

As part of making it possible to do some more flexible workspace layout for MSM contract editor, went a bit off the deep end refactoring `Toolbox` to be a prototype and introducing a new `EditorWorkspace` to make it possible to have two fully separate `<svg>` workspaces (in contrast to *sub*-`Workspace`s that are currently used for the mutator dialogs/flyouts and are simply nested `<g>` groups).

This has two big components:

* Make the static top-level `Blockly.*` mouse handling / positioning code a new `EditorWorkspace` prototype
* Make `Toolbox` a prototype, initialized per-`EditorWorkspace`

A few organizational things I could use feedback on—

* Should `EditorWorkspace` *have* a `Workspace` rather than *be* a (inherit from) `Workspace`?
* Are there better names/concepts for `EditorWorkspace`/`Workspace`? I am considering renaming `EditorWorkspace` to `Workspace` and `Workspace` to `SubWorkspace`, but would want to do that as a separate commit since it's changing what an existing name references.
* Would it be better for `Blockly.mainWorspace` to be of an `EditorWorkspace` type (rather than having to reference `Blockly.mainWorkspace.editorWorkspace`, callers could then just assume `Blockly.mainWorkspace` has the EditorWorkspace properties)

Re: testing, I shored up most of the signal scoping issues that arose (because we're not using so many global static references, certain signal calls now need `this` references which didn't before). I will also do some more thorough manual testing of potential edge cases and cross-browser tests.
Nope, will remove. Previously had a bunch of things in-line and didn't want to pull out methods since I'll be moving where this lives.

Sorta following the inline-ordered-code-scope method [John Carmack mentions here](http://number-none.com/blow/john_carmack_on_inlined_code.html)—

> Using large comment blocks inside the major function to delimit the minor functions is a good idea for quick scanning, and often enclosing it in a bare braced section to scope the local variables and allow editor collapsing of the section is useful. I know there are some rules of thumb about not making functions larger than a page or two, but I specifically disagree with that now -- if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially.

(but this is purely visual in JS since there's no block scope)