[FIXED JENKINS-21622] Release workspace leases (and avoid @2) even if post-build actions throw LinkageError.

(Forgot that Run’s are unmarshalled in place after a special constructor is called, so there is no need for readResolve or other tricks.)
Also calling RunListener.onDeleted outside of the Run lock to avoid problems with things like ChangeLogHistoryRunListener.

From a random failure of BuildTriggerTest.testMavenBuildTrigger:
java.lang.AssertionError
	at hudson.model.Run.setResult(Run.java:425)
	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:722)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.cleanUp(MavenModuleSetBuild.java:1054)
	at hudson.model.Run.execute(Run.java:1733)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)

JENKINS-22052 is not fixed by this for existing Job types like ExternalJob which still do not use lazy loading.

When printing AbstractBuild.BuildingRemotely message to log, also indicate any (non-self) labels of the node.
This is invaluable when diagnosing problems with a build on a cloud slave after the slave has been deprovisioned.
If the node name by itself does not indicate what type of machine it was, you would have a hard time guessing.

[JENKINS-18224] Introduced Actionable.replaceAction, allowing getActions() to be deprecated except for subclasses.

Hold on to the lease until the very end.
Previously, the lease was only held until the main build section is over, before publishers start running.

[FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble.
JENKINS-16194 and an analogous but opposite bug fixed more simply by introducing a separate NONE constant.
Also numberOnDisk did not get updated properly after a build was deleted, causing double loading of build records in some cases.

[JENKINS-16845] Properly report the IllegalStateException, rather than throwing an NPE producing the exception message.
java.lang.NullPointerException
	at hudson.model.Run.getFullDisplayName(Run.java:711)
	at hudson.model.Run.toString(Run.java:706)
	at java.lang.String.valueOf(Unknown Source)
	at java.lang.StringBuilder.append(Unknown Source)
	at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:218)

This allows administrator to remove this problematic file.

And since it's now a symlink that points to another symlink that then
points to the real stuff, we need recursive onion peeling.

Based on comments from Jesse, revising the fix.

I'm now putting permlinks inside the builds/ directory to avoid the computing hassle involved in the split $JENKINS_HOME.

What we historically had in $JENKINS_HOME/jobs/JOB/lastSuccessfulBuild is also now subsumed by this feature. I initially attempted to create these permalinks in the buidl root directory, but turns out those symlinks aren't the same name as the ID of permalinks, so it doesn't mesh well.

And finally, a test!

Require POST for various operations.
(cherry picked from commit 36c86243)

Conflicts:

	core/src/main/java/hudson/model/AbstractBuild.java

java.lang.NullPointerException
	at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:104)
	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
	at com.cloudbees.hudson.plugins.modeling.impl.builder.BuilderImpl.perform(BuilderImpl.java:58)
	at hudson.plugins.m2extrasteps.M2ExtraStepsWrapper.executeBuildSteps(M2ExtraStepsWrapper.java:166)
	at hudson.plugins.m2extrasteps.M2ExtraStepsWrapper.access$200(M2ExtraStepsWrapper.java:43)
	at hudson.plugins.m2extrasteps.M2ExtraStepsWrapper$1.tearDown(M2ExtraStepsWrapper.java:137)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:817)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:490)
	at hudson.model.Run.run(Run.java:1442)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:239)

Stapler doesn't understand doXyz method overloads, so in general it's
not predictable which form it'll invoke.

Clearly state that FingerprintAction, not UpstreamCause, is used for all upstream/downstream methods in this class (contrary to what you might expect).

Why, you may ask?

Think of neighbors A, B. If A points to B but B doesn't point to A, when B is removed A will still end up pointing B as the next build.