These refactorings are essential in anticipation of a new quicksetup application for the upgrader feature (issue 598).  These changes were reviewed by Josu. 

1.  Establish the concept of an Application (Install, Uninstall, Upgrade, Revert etc.) so that common drudgery (progress notification, message formatting, look and feel, user input, file management etc.) can be handled by a common base class (newly created AbstractApplication).

2.  Establish clearly defined interface between the framework (QuickSetup) and the applications.

3.  Replace classes currently defined in each application's package having lots of commonality with common classes (see new classes in org.opends.quicksetup).

4.  Miscellaneous cleanup mostly handled by my IDE (fix Javadoc problems, optimize import statements etc.)

This commit also:

- made ProgressSteps an interface that the application specific enums implement.

- moved the uninstaller specific user data back into a UninstallUserData object.  For now I've left the installer's UserData to be more of a default since it has lots of properties I imagine would be useful for the upgrader.

- added a new system property org.opends.quickstart.Application.class for specifying the application class of the Application to be instantiated.  I've done this to remove some of the logic involved in determining which application to create in QuickSetup (if (isWebStart())..., if (isInstaller())...).  The create-webstart-standalone script now generates this property as do the *Launcher classes.  Applications are now created in the Application.create() method.

- QuickSetup now creates the application during the init phase rather than waiting until the launch*.  This so that the application can supply the user data necessary (specialized user data if necessary as is done by the uninstaller application).