[FIXED JENKINS-20514] Add a core extension point to allow plugins to contribute to the checking of assigned labels

If slaves are late to come online after a Jenkins startup, we will see a huge spike of builds as Jenkins attempt to get a workspace for polling.

Should follow this statement:
"Called after a job has its configuration updated."

JENKINS-17108. This solves the problem with ItemListner.onUpdated not being called if the project was disabled/enabled by pushing the button on the project page. Also solved the problem with ItemListener.onUpdated not getting called if the project description was updated using the edit description on the project page.

Integrated bytecode-compatibility-transformer that allows core to
do signature changes on properties that plugins might depend on.

The library performs necessary bytecode transformation to achieve this.

The first use of this is to fix plugins that looks for List
AbstractProject.triggers, thereby resolving JENKINS-18677.

For the time being, I'm not loading such compatibility annotations from
plugins, but I did code that in PluginManager. Let's see how this
feature work out for a while in the core, and if it looks stable and
solid, we'll open it up to plugins at that point.

Ensure the addTrigger and removeTrigger methods only use methods that are
supported by DescribableList. This means no indexed operations are
supported, so use only Iterator#remove and Collection#add

Add Integration Tests to ensure methods work as expected

java.io.IOException: …/builds/2013-07-11_12-21-02 is in use
    at hudson.model.Run.delete(Run.java:1363)
    at hudson.tasks.LogRotator.perform(LogRotator.java:133)
    at hudson.model.Job.logRotate(Job.java:406)
    at hudson.model.Run.execute(Run.java:1638)

[JENKINS-3265] [JENKINS-17341] Even if older plugins throw an NPE during reload, continue loading job.

which may be offline, or wiped.

Unlike the bug I originally reproduced, in which the parent had some builds
but the context in which the new build was scheduled omits a parent,
this seems to be due to a case in which there is no build record at all for the parent.
No idea how that could happen (getLastBuild should return even a running, failed, or aborted build),
but @treydock reports a stack trace in 1.509.2 which implies this.
So fixing null safety; will not prevent an exception but will report it more gracefully.

This helps a lot when mocking AbstractProject in unit tests, because so I don't have to suppress the constructor with PowerMockito

(cherry picked from commit d8f74cf8)

Use DescribableList to handle the copy-on-write semantics correctly. The vector class just doesn't cut it, and we've been setting a new value to this field, which will violates all sorts of the concurrent programming practice.

This change has the nice side effect of removing {{class="vector"}} from the persisted XML. A test is added to make sure we can still read back such an XML.

IMO this needs further refactoring - respect separation of concerns:
it's not AbstractProject's call to trigger a node offline

Added Queue.schedule2 to allow the caller to retrieve the existing item in the queue. AbstractProject.doBuild() changed the behavior a bit to reply 201 if the item was already found in the queue (instead of a new one created.)

As Jesse pointed out, contextual information is often useful in authenticating the build, which means we need to take Queue.Item (initially AbstractBuild was the parameter, which provided the context, and I failed to accommodate that in transition to AbstractProject.)

To still allow Queue.Tasks to provide a meaningful value fallback to Queue.Task.getDefaultAuthentication() as opposed to hard code it to ACL.SYSTEM. This allow plugins like remote-terminal-access to supply a meaningful secure value without forcing a configuration change to the user.

This is necessary because a part of the access control is determining which Executor can accept which Queue.Task, so we can't have the authenticator taking Executor as a parameter.

I briefly thought about changing ExecutorAuthenticator to authenticate Queue.SubTask, but doing this intelligently is very difficult as an authenticator wouldn't really be able to make any sensible decisions unless it checks for specific subtypes (think of the dist-fork plugin and the remote terminal access plugin that implements Queue.Task.) So I made the change to have it accept AbstractProject, which is really the primary use case anyway.

The relevant classes are renamed to better represent what it does now.

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

Expanded MockFolder to be a ViewGroup so that it is possible to test views inside folders,
and generally fixed it to service Stapler hierarchies properly so that WebClient-based tests can work.

(Not touching the icon since I do not feel like playing with Inkscape; would be a nice pull request for somebody.)

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