Refactor App Engine deploy code

Closely related to #2416, which requires an overall restructuring.

The new global WAR/JAR deploy flow has a bit of different characteristic from the current std and flex deploy flows in that, the former isn't associated with a project, while the latter two shares the common assumption that they require a project.

### Command Handler ###
The three command handlers can share a lot of code, and we do so with inheritance.
```
DeployCommandHandler --+-- StandardDeployCommandHandler
|
+-- FlexDeployCommandHandler
|
+-- FlexExistingArtifactDeployCommandHandler
```
A project is a determinant factor for several important things: deploy preferences (i.e., whether if is a project-scoped preference or not), creating a staging delegate (responsible for staging a particular project?), creating a deploy dialog (the std and flex deploy UI need the project info), etc.

### Deploy Preferences Panel ###
```
DeployPreferencesPanel
|
+-- AppEngineDeployPreferencesPanel
|
+-- StandardDeployPreferencesPanel
|
+-- FlexDeployPreferencesPanel
|
+-- FlexExistingArtifactDeployPreferencesPanel
```
There is a similar abstraction discrepancy in this hierarchy. The std and flex panels (in fact, the `AppEngineDeployPreferencesPanel` base class) always assumed there is a project, while the new global deploy panel doesn't. However, the code look mostly OK, compared to the command handler case. (The new panel just doesn't make any use of the "given" project, which is null.)

### Deploy Preferences Dialog ###
```
DeployPreferencesDialog
|
+-- StandardDeployPreferencesDialog
|
+-- FlexDeployPreferencesDialog
|
+-- FlexExistingArtifactDeployPreferencesDialog
```
The same gripe about the abstraction. The new global dialog creates a panel with a `null` project.