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.

Added a new overloaded version that works on a project.

Updated CoreEnvironmentContributor accordingly.

The code is smart enough to compute a minimum set of builds to remove to
restore order consistency.

Also cleaning up variable names to be less misleading.

Note that new File("target") is really a bad idea since we cannot predict the CWD in effect when Maven is run.
(From the standard bin/mvn launcher, it seems that it will always be *some* Maven project at least.
This may not be true for Maven run embedded from various tools.)
But leaving that as is for now, since it is not clear how else we would find the project location.
(new File(env.description().getTestClass().getProtectionDomain().getCodeSource().getLocation().toURI()).getParentFile() might work but it is pretty hacky.)

[FIXED JENKINS-18178] Reverting an inessential part of the fix of JENKINS-16301 since it broke some Maven builds.
Apparently the Maven 2 process factory fails to adequately insulate the Maven process from Jenkins library dependencies;
if you specify a build extension that can override dependencies used by Jenkins core classes!
A real fix would involve changing class loader delegation, since presumably similar bugs could still occur.

[FIXED JENKINS-18898] ToolInstallation.getHome may be null, and buildEnvVars must take that into account.

Clearer display of log messages: chronological order, and coloration of repeated vs. fresh metadata.

Also ensuring that Jenkins configuration is saved after new XML is POSTed.

If so, retry with (6+) slave JVM, setting maven-{compiler,surefire}-plugin properties to point to original.

Integrated the fix into Jenkins

... with a test case. The fix is in Stapler.

System.nanos() returns a monotonically increasing value that is not related
to wallclock time. Use System.currentTimeMillis() instead.

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.

The earlier fix by @ssogabe broke the test. This fix corrects the
problem properly.

The reason this error happens with some plugins is that if there's an
input field whose name is "on", then even after prototype.js extends
an element object, "form.on" will refer to the input element, not the
prototype.js function to add an event handler.

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.