[REVIEW_ONLY] Splitview

* This pr creates a split view of either side-by-side or upper-lower views of 2 different files.
* From the View Menu select "Split Vertically" or "Split Horizontally" to create a second pane. 
* Selecting the menu item again will collapse the panes down to a single pane (merging the two working sets and showing the current view)
* Selecting the opposing menu item will just reorient the views without disturbing the documents
* A blue outline currently denotes the active pane.  Functions such as opening a document, searching, etc... will target the active pane.  Functions like Close All will target both panes and close all documents.
* Lint will work on the currently focused editor
* Images are not supported and viewing images has been disabled in this build
* The UI as it works now is temporary.  A UI treatment story will come next with @larz0 UI treatments

Known Issue:
https://github.com/adobe/brackets/issues/8513#issuecomment-49796161
The selection is getting reworked with @larz0 UI treatment and will be addressed at that time

I encourage anyone who has cycles to test this.  Obviously this is a big change and needs quite a number of eyes on it.
I'm a little confused by the control here -- it might be making Editors too special...  It feels funny that sometimes MainViewManager controls when a pane becomes active (via a click listener), and sometimes EditorManager controls it (by dispatching `"activeEditorChange"`).  If there are cases where an Editor can get focus without a click (and without otherwise going through another API here like `setActivePaneId()`)... then couldn't such cases exist for non-Editor views too, like the image viewer?  So it seems like whatever mechanism handles those cases should be something generalized, rather than an Editor-specific special case.
 
One way of making this more generic is to add a `"focus"` event to the View interface, so any View has the ability to tell MainViewManager it got focus.  Two potential issues:
 
1. I haven't really thought through how that would work vis a vis focusing an inline editor activating its parent pane
2. It seems to make the click listener here redundant -- should we just remove it?  But can we trust all custom views to remember to notify us anytime they receive focus?  If not, maybe it's better still to just install a global focus tracking listener here and don't rely on anyone else's notifications...  But IIRC there were some really delicate timing wrinkles with the timing of DOM focus events vs. CM focus events.  We'd have to be very careful not to break anything there.