Cf.: https://github.com/jenkinsci/subversion-plugin/pull/83

In 1.509.2, probably due to a bad Groovy script:
java.lang.ClassCastException: hudson.model.Hudson cannot be cast to hudson.model.Slave
	at hudson.slaves.SlaveComputer.getNode(SlaveComputer.java:176)
	at hudson.slaves.SlaveComputer.getNode(SlaveComputer.java:92)
	at jenkins.model.Jenkins$9.compare(Jenkins.java:1547)
	at jenkins.model.Jenkins$9.compare(Jenkins.java:1543)
	at java.util.Arrays.mergeSort(Arrays.java:1270)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.mergeSort(Arrays.java:1282)
	at java.util.Arrays.sort(Arrays.java:1210)
	at jenkins.model.Jenkins.getComputers(Jenkins.java:1543)

(Also relevant to JENKINS-22395 diagnostics.)

- coding style was not matching the rest of Jenkins
- IOUtils.closeQuietly is a lot more concise way of achieving the same
  thing.
- AtomicFileWriter.abort() does close, so no need to close it one more
  time.

Bringing this to the parity with ParameterizedJobMixIn.doBuild()

Instead of returning JSON, it returns "201 Created" and responds with the location of the queue item, through which the caller can track how it passes through the queue and eventually gets built/cancelled.

The approach in pull request #750 that relies on
AbstractProject.getQueueItem() is inherently unreliable, because
item can be immediately built before the JSON is rendered, or it might
corresponds to other queued items if the build supports concurrent
builds, etc.

[JENKINS-20974] RunParameter with filtering enabled should not include builds which have not completed

display name.

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

Hoping nobody uses it programmatically.

Also, added @Restricted to the new one.

Reduce classloader activities.

This brings in Stapler and commons bean-utils that we don't need on the
slaves.