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.)

[[JENKINS-16301] Use a buffered input stream to get somewhat better performance also from Maven archiving.
Introducing Util.getDigestOf(File) as a convenience.

[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.

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)

Refactor ListView to allow to set includeRegex programmatically

Merge branch 'maven-3.1.0' for maven 3.1.0 support in Maven Integration Plugin

Unclear what Run.getEnvironment is supposed to return after the build is complete.
In particular, SubversionSCM calls this during polling to substitute variables in e.g. repo URL.
Presumably in such a case node-specific variables such as ToolInstallation.home would be irrelevant.
But in general should this reflect the “current” computer (if any), or the computer on which the build ran?

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

Fix javadoc for QueueTaskDispatcher and NodeProperty

Fix javadoc for @see reference in MatrixAggregator

Fix SCMTriggerCause javadoc to deprecated constructor

Fix javadoc link in MatrixExecutionStrategy

Uses the outer class plus the inner class to name the argument, which
satisfies javadoc.

There is a BuildableItem interface in hudson.model, but the references
in these files to BuildableItem objects are refering to an inner class
of the Queue object, not to the interface defined in huson.model.  The
javadoc link improvement may help authors see that difference.

http://javadoc.jenkins-ci.org/hudson/matrix/MatrixAggregator.html#startBuild()
has an @see reference which should be a link.

http://javadoc.jenkins-ci.org/hudson/triggers/SCMTrigger.SCMTriggerCause.html
includes a deprecated constructor with an @{link } reference to the
preferred constructor.  That link is broken in the current javadoc.
This fixes the broken link.

Fix javadoc link from deprecated DumbSlave constructor

See https://groups.google.com/forum/#!topic/jenkinsci-dev/yf8i1v5XSDg