Made the in-flight build survive the reload from the disk.

Report 100 recent builds in the JSON API, including in-progress builds.

Not reporting all the builds since this would nullify the lazy loading
effect. Will introduce a pagenation API that supports retrieval.

Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)

Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.

[FIXED JENKINS-15796] NoClassDefFoundError: 'Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX' from SwapSpaceMonitor.
Not fixing actual linkage error—JNA issue of some kind—but ensuring that Jenkins reports it only once.

Integrated the new version of Stapler that includes the fix.

[FIXED JENKINS-16474] Winstone and executable WAR upgraded to actually support --httpKeepAliveTimeout.

These are one time URLs, and this change aligns them from other /static/
links that serve 365 days expiration period.

[FIXED JENKINS-17087] getSortedDescriptorsForGlobalConfigUnclassified needed to avoid clobbering GlobalCrumbIssuerConfiguration in Jenkins.doConfigSubmit.

(Ah, the joys of dynamic typing!)

Disable authenticode verification on jenkins.exe and jenkins-slave.exe
by generating a proper application configuration file.

See: http://msdn.microsoft.com/en-us/library/cc656914.aspx
See: http://msdn.microsoft.com/en-us/library/bb629393.aspx
See: http://support.microsoft.com/kb/936707

Added backward compatible data loader and a corresponding test case.

HyperlinkNote shouldn't emit the absolute URL.

b5ed3199 already caught linkage errors but then unconditionally returned false from Util.isSymlink, which is wrong;
we want to fall back to the generic File.canonicalPath comparisons in this case.

There are several incompatibilities in XStream 1.4 that resulted in our
changing the core, but according to the text search on all the public
plugins, none of these changes affect the 600+ plugins we have today.

However, it is still possible that there are some parts of XStream 1.3
that plugins depend on but the core doesn't depend on --- we won't be
able to tell those problems at this point.

Not sure what has happened --- perhaps some of the markers were off and
that confused the update script?

Will need to watch out for the next RC run.

Fixes: Maven2 builds with non-standard test mojos failed.

[FIXED JENKINS-16844] MenuItem.post allows context menu items like Build Now to send a POST request.
Currently just shows a hover notification; TBD if there are use cases for displaying the response.