Extension:UploadWizard/Refactoring goals

This is a summary of what User:MarkTraceur (WMF) wants to accomplish in the large refactoring of UploadWizard that is underway as of 2014-08-22.

MVC design
Models:
 * Upload - should basically hold all of the information currently found in the DOM and in the UploadWizardUpload class.
 * Description - should handle things like that get added to the description field of the information template.
 * Details - should be a high-ish level interface for interacting with multiple separate information templates. will be the first supported template, but I see no reason not to support more.
 * Depending on how quickly the structured data work goes, we may want to implement the high-level metadata API instead...not sure yet. This will probably be the last model to get written.

Views:
 * Steps - these will get created automatically(ish) by the step controllers (see below), and they'll control the actual UI of the views.
 * Upload - controls per-upload UI elements, emits events to the upload controller to affect its state. Modeled after parts of UploadWizardUploadInterface.
 * Wizard - controls global UI elements like the arrow steps.
 * Details - will have the per-upload details UI, and fire events up to the controller class (below) when things happen.
 * Deed - will have a single UI for choosing a deed, which could be used to pick one for every file in the batch or for picking a deed for one file.

Controllers:
 * Steps - handle switching between steps, handle operations on uploads per step, and also manage the upload list on entry and exit.
 * Upload - handle operations on uploads that are self-contained - basically modeled after some of the code in UploadWizardUpload.
 * Wizard - the current UploadWizard class, but much smaller as other things descend into the above controllers.
 * Details - pretty much what's in UploadWizardDetails right now, with some generalizations built in. Will fire events up to the upload class when changed.
 * Deed - basically what's in UploadWizardDeed right now, again with generalizations and events.

Acting on uploads instead of groups
Changing the pipeline to act on uploads individually, instead of acting on an entire batch at once, will make it easier to change the workflow. To that end, we'll prefer making uploads independent of the rest of the process, and just hook them up to other parts of the process where appropriate.

Moving Flickr code into its own classes
Part of this will be moving Flickr handler code into a separate group of classes - subclasses of uw.controller.Upload et al., depending on what actions need to be changed. This will be superior to the current system of conditional branching.

Events, events, events
We want there to be more events, and not on the DOM. Working with OOJS's EventEmitter class should give us more flexibility in our code, especially when we look down the road to building alternative interfaces and upload types.