This provides generic consumer of ToolInstallation to expose
ToolInstallation to the build.

made sure that even if a bug similar to what was just fixed in the previous commit re-surfaces, we still won't kill the master JVM by eating its memory

Previously, a forked life cycle resulted in MavenBuildProxy2.start/end callbacks. When a module X build forks a life cycle and comes back to building module X, end callback from the fork completion made Jenkins believe that it's not building any module, when Maven is actually coming back to building module X.

So if the sequence of mojos that follow the forked mojo produces a lot of output, it can saturate memory (and even if it doesn't, Jenkins fails to capture the entire log for a module.)

This fix also addresses the synchronization problem, so that when we do split the log, we make sure all the output from Maven prior to that indeed arrived to the master.

Commented out getActions() as returns new copy of action list and thus breaks e.g. JUnitResultArchiver, which adds
actions directly to the list (build.getActions().add(action)).

Conflicts:
	changelog.html

The trick for backward compatibility is in the default implementation
that grants View.READ to those who have access to items.

Use a ping timeout of 3/4 of the ping interval instead of the default
4 minute timeout.
This happens to workaround an issue in the remoting PingThread
implementation which causes the ping to busy wait for the timeout
period instead of keeping the channel alive.

Fixed JENKINS-13129: Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup

[FIX JENKINS-12994] Quiet period is blocking other jobs in queue

Added another hyperlink to the console output of a blocked matrix build configuration.
thanks

There's some expected performance gain since people often deploy
$JENKINS_HOME over NFS.