JBDS-2721 - intorduced authenticator for downloadRuntimes, plus fully refactors runtime

This PR is a bit hefty, but it's not overbearing.

Introduces new API, interfaces, extension points, for giving a downloadRuntime object an authenticator and the ability to put US for the authenticator.  THIS IS NOT A FULL SOLUTION. This only solves the problem from runtimes. ASTools will still need to implement these points. 

To do this, a 6-class framework called taskmodel from wtp needed to be used. Unfortunately, runtime has no dependencies on wtp and shouldn't, and the taskmodel framework is internal in wtp.  This framework is a UI framework (basically, a wizard structure that provides the ability to make tree-based workflows, where each page can have children pages depending on what the current wizard model says. It is very very easy to change the next page based on what's selected in the current page. This framework is very strong, small, and amazingly useful. 

Since other plugins will almost certainly want to use this framework (discussions with some have had people very interested in it), it should live in foundation.   Foundation does not have a .ui plugin yet, so,  

2) Adds the taskwizard framework to a new plugin named foundation.ui. 

With runtime now depending on foundation, and completely cleared of dependencies on wtp, it became clear that runtimes should not depend on common at all. This required the addition of 2 classes (IMemento and XMLMemento) to foundation. This will also help plugins like JMX or ASTools to remove their copies of this class. 

With the new wizard framework, the code for the DownloadRuntime wizard was cleaned up a little (trying not to change too much) and converted to WizardFragment objects instead of IWizardPage objects.  The changes required for this were not drastic. 

Finally, many files were moved around into internal packages. 

Due to all these changes, the version of runtimes has been bumped to 3.0.0

Usage scans were performed, and all of Base, Server, JavaEE, and Central, were built locally (without running tests) with no errors. As of now all changes are api compatible for current users, but strictly speaking, it is not compatible because many public classes are now (or will be shortly) internal. 

I would like to eventually NOT expose most of the packages runtime.ui currently exposes. I cannot remove these immediately, though, until central makes small changes to not use the internal classes.