exposed data about installed plugins, installable plugins, update center jobs, etc., to the REST API

[Fixed JENKINS-13129] Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup

changed bundled plugin detection, added unit test

Fixed the file overwrite problem on Windows.

Bundled plugins should be laid down as *.jpi, with proper measure to
migrate existing bits.

- init task needs to be filtered down to only include those that are newly added.
- newly added plugin needs to be a part of the 'plugins' field

Max Spring discovered a stack overflow in http://jenkins.361315.n4.nabble.com/channel-example-and-plugin-classes-gives-ClassNotFoundException-td3756092.html that pointed this call into thread context classloader (TCL) as the culprit. Independently, Paul Sandoz discovered the same issue in our products. If TCL is another classloader that delegates to UberClassLoader (UCL), this code causes infinite recursion.

And moreover, given the goal of UCL, it seems wrong that this class is changing behaviour based on contextual information like TCL.

 In looking at 4de81f1e, the change was introduced to make sure XStream unmarshalling invoked from Plugin.start() would see the classes in that plugin. This was an issue back then when plugins are prepared and loaded one by one, as UCL didn't have visibility into plugins being prepared. But in the current Jenkins, classloaders for all the plugins are prepared, before any plugin gets started, so by the time Plugin.start() runs, UCL is fully functioning.

 Therefore, there's no need to consult TCL for the purpose of resolving its own classes. I could have also removed the code that sets TCL, but because some libraries often depend on TCL and doesn't properly look at caller class, I'm leaving it in, even though it's generally a bad practice to rely on TCL in multi-classloader apps like Jenkins

We weren't actually enforcing the initialization order at all, as
sorting was based on the plugin name.

Just import changes, from hudson.model.Jenkins -> jenkins.model.Jenkins,
and Javadoc comments.
Signed-off-by: NNigel Magnay <nigel.magnay@gmail.com>

Signed-off-by: NNigel Magnay <nigel.magnay@gmail.com>

to be able to get in an other place (sure git could be better :-) )
some issue when using maven 2
some stuff to do more in maven 3 build (recording mojo execution etc...)



git-svn-id: https://hudson.dev.java.net/svn/hudson/branches/main-maven3-support@36643 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@36008 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@35980 71c3de6d-444a-0410-be80-ed276b4c234a

```-----
Merged revisions 32975,33588,33697,34342 via svnmerge from 
https://www.dev.java.net/svn/hudson/branches/downgrade
```

.....
  r32975 | kohsuke | 2010-07-16 21:27:59 +0200 (Fri, 16 Jul 2010) | 1 line
  
  committed my partially modified version
........
  r33588 | dienomight | 2010-08-05 09:42:36 +0200 (Thu, 05 Aug 2010) | 13 lines
  
  Added getBackupVersion (UpdateCenter)
  downgrade button now shows version of backup war file
  
  Added HudsonDowngradeJob (UpdateCenter)
  downgrading process is works now as HudsonUpgradeJob
  
  Changed rewriteHudsonWar (Lifecycle) 
  backup file is deleted when downgrading
  
  hudson/model/Hudson/downgrade_success.jelly is no longer necessary
  
  Changed rewriteHudsonWar(WindowsServiceLifecycle)
  hudson run as windows service creates backup during upgrading
........
  r33697 | dienomight | 2010-08-11 17:09:48 +0200 (Wed, 11 Aug 2010) | 8 lines
  
  committed changes:
  "plugins downgrade functionality"
  added: 
  * PluginDowngradeJob in UpdateCenter
  * getCanDowngrade & getBackupPath & getBackupVersion in PluginWrapper
  * additional "previous version" column in installed.jelly (PluginManager) with downgrade button (when it's possible to downgrade)
  * doDowngrade in PluginManager
  * deployBackup in UpdateSite
........
  r34342 | dienomight | 2010-09-03 09:52:13 +0200 (Fri, 03 Sep 2010) | 12 lines
  
  Code improvements: 
  jelly files:
  *I put text inside ${%} so it would be available for translation.
  UpdateCenter: 
  *changed getCanDowngrade to isDowngradable
  *getBackupVersion use JarFile class to get version of .war backup
  PluginWrapper:
  *changed getBackupPath to getBackupFile
  *getBackupVersion use JarFile class to get version of plugin backup
  PluginManager:
  *changed condition in doDowngrade method
........


git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@34543 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@32004 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@31831 71c3de6d-444a-0410-be80-ed276b4c234a

- click category heading on Available tab to show/hide plugins in that category
- add initial sort for plugins on Installed tab
- no mouseover bgcolor for Advanced tab


git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@31819 71c3de6d-444a-0410-be80-ed276b4c234a

to avoid possible ConcurrentModificationException when optional dependencies are
being processed in PLUGINS_LISTED phase.


git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@31481 71c3de6d-444a-0410-be80-ed276b4c234a

when submitting proxy settings.


git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@30454 71c3de6d-444a-0410-be80-ed276b4c234a