The current implementation is not robust against blank display name

Seems rather unlikely, but none the less it is a possibility. Not sure how we should handle this though:

* We do not want to hold the Queue lock while performing I/O as that will grind everything to a halt
* We do not want a big fat lock on all nodes
* If we have a per-node lock then the save everything method may have to grab them all

In short, it gets ugly real fast.

For now, I believe that the risk is very low as releasing a lock does not intrinsically deschedule a currently running thread so the likely course of events is that the thread will release the lock and at least start the save before a competing thread could acquire the lock update remove the node release the lock and delete the node's directory

- Also tidy up some of the mess logic in both #1866 and #1860

This pull request integrates https://github.com/jenkinsci/jenkins/pull/1712

This pull request integrates https://github.com/jenkinsci/jenkins/pull/1769

[FIXED JENKINS-30730] Prevent ClassCastException in Abstractbuild::reportError() if the build step is not Publisher.

This pull request integrates https://github.com/jenkinsci/jenkins/pulls/1851, which is a reworked version of https://github.com/jenkinsci/jenkins/pull/1846 from @fbelzunc (no original codelines left)

The new version of the BCT does not generate stackMap if the original code
did not contain stack maps.  Further more the new version takes a
classloader to use so that it can load classes when searching for the
common parent class.

Fix HistoryPageFileTest tests
Fix int parsing in JavaScript
Fix some JS glitches

This reverts commit 3c471f1f.

This reverts commit df4bb2de.

Nodes.updateNode(): Call Jenkins.getQueue().scheduleMaintenance() to be sure to update builds in the queue with the change done in the node (+  Add since 1.634)

If a job is renamed to a string with trailing whitespace, exceptions are
thrown as the application attempts to rename the job directory in the
file system, and the job can be neither deleted nor renamed again
through the UI. This problem occurs only when renaming a job, and not
when initially creating a job, because job names are trimmed when first
created.  This change trims the job name for rename operations as well,
so that the name-setting behavior is consistent across create/update
operations and inadvertent leading/trailing whitespace is removed before
it can cause problems.

TopLevelItemDescriptor mistakenly suggested a newJobDetail, which is deprecated. In general it should now be newInstanceDetail.