[JENKINS-17713] [FIXED JENKINS-14362] These fixes were (mistakenly?) recorded for 1.518 rather than for trunk.

Integrated the new version of Stapler that fixes them.

properties that are applicable to the master node only and node properties
that can be applied to all nodes

[JENKINS-15380] noting. Ref. https://github.com/jenkinsci/jenkins/commit/029701ce3d109dc1a81991b09d23ba774a30fc2a

The plan of the record is that we start producing 1.6 class files and
see if people start complaining. If we hear from users, we'll re-visit
our decision, and if we don't, then we'll start using 1.6 features
everywhere in the code.

The slave launch thread is another background thread, and it should run
like a super-user

This can track items as they go through the queue.

This reverts commit 9fb2a025.

[FIXED JENKINS-16974] Unsafe to define a function in <script> without a generated name, as it could clash with functions defined in unrelated *.jelly that happen to included in the same page.

Noting the fix.

- integrated the newer release of remoting
- jar caching won't work with class file directory, so plugin
  WEB-INF/classes are now exploded as WEB-INF/lib/classes.jar
  (This should also solve the problem of slow plugin extraction in the
  presene of Anti-virus software on Windows.)
- because the structure of the exploded jar file has changed, I changed
  the up-to-date check timestamp file name to force re-extraction in
  existing installations.

This came from Alpha CSP guys during JUC Israel. The remote API needs to expose a better way of tracking a submitted task.

[FIXED JENKINS-17125] FingerprintAction no longer need persist the build field thanks to new RunAction2.

[FIXED JENKINS-15652] “Solving” errors by just return null from ALLRM.search and reducing to one-line warnings.
@kohsuke confirms that the intent of throwing AIOOBE was to track down definite code errors;
but in at least some known occurrences of this bug, the problem is invalid data:
build records on disk with <number>s that are duplicated and/or out of order.
Since that violates the precondition of the class, we do not pretend to successfully search for such records.
At some point it would make sense to have the code detect anomalous conditions and initiate a builds folder cleanup.
Take only the last build of a given number, and discard any earlier with higher number.
I.e. just set <number> to 0 or something and ignore such builds, or rename build.xml to build-broken.xml.