JS event rearchitecture, search + diff ajax, definitions spinner....

Ok, this is a big one, I know.

**Don't merge yet. I still have to get functional tests passing and a test toward included Python written. Feel free to review, though.**

- JS event rearchitecture*: removed Dispatch, events are now scoped to primary view within each view section: header, main, sidebar, drawer, breakaway
- Search and diffs now load via ajax (new browsers)
- Url hashes update with wayfinding header (new browsers)
- Implemented new page title scheme both in Django and JS
- Definitions url spinner for while the definition is loading
- Hopefully just general making things more extendable, understandable, concise
- Implemented new formatting for GA events, implemented some newly tracked GA events (I think)
- Moved inline definition templating into Django

----------------
(for the curious and for people who will have to dive in)

*Why: basic architecture from the early days assumed that all content had the same properties as a reg section. This meant that bringing other types of content into the fold (search, diffs, subparts) was hacky. Prior eventing was difficult to understand and near impossible to document or keep track of. Also, it tried to hard to be magic-y. "section:open" means something very different to, say, Main view vs Sidebar view, so that's ok now.

Most everything - logic within views, GA event scope, etc - relies on a cascade of Backbone's ```this.options``` that gets passed into View constructors. Event and options property names are (fairly) consistent. This only really falls apart at id on search and diffs as I don't think we need to implement a proper representation of version at the model level, and so keeping the url as the unique id in models deals with the problem of having different representations of a section - for example, 1005.2 vs the diff for 1005.2 between versions 2011-11111 and 2012-12121, etc.

Making the sequence for changing content mostly identical (mostly by View inheritance and having kind of a master View for each section) also means that we can update things based on async processes in a more reliable and easy way. The tradeoff is that things have gotten kind of callback-y in the Main/Child Views View creation/rendering cycle.