Don't break Windows XP, fall back gracefully to no-op.

Conflicts:
	changelog.html

Otherwise your disk will fill up with (large) /tmp/hudson*tmp/ dirs when running plugin tests.
(Would have been better to use e.g. TemporaryFolder, but that would require incompatible changes to the test harness.)

In particular, explain how to free an external resource when a slave is
gone.

If for some reason the numExecutors field gets out of sync with executors.size() (for example this can happen if an executor swallowed an interrupt signal without properly processing it), then a further attempt to call setNumExecutors(n) results in a no-op.

Given that these things can get out of sync, a smarter thing to do is to always compare where we are (the "executors" variable) and where we'd like to be (numExecutors), and make corrective actions.

This particularly affects a zombie computer. The sequence to kill a Computer first involves waiting for all the executors to quit. If setNumExecutors(0) becomes no-op, a zombine computer never gets killed.

This broke the context menu for actions contributed via TransientComputerActionFactory (at least).

To reproduce SUREFIRE-974 prior to this fix, pick an arbitrary group class to (not) exclude:
mvn -f test/pom.xml -Dtest=CoreJellyTest -DexcludedGroups=hudson.ExtensionPoint test

This is based on
http://stackoverflow.com/questions/13113142/gmaven-build-fails-with-an-api-incompatibility-was-encountered

Instead, it shows a small 'v' icon to the right that needs to be clicked
to open a context menu.

[FIXED JENKINS-17330] FilePath.installIfNecessaryFrom should avoid routing download over remoting channel.

Otherwise you get nonsense like this:
Cannot delete this build, because it is #3 depends on this

confirmDelete (and confirmDeleteAll) already say why a build cannot be deleted (and prevent you from proceeding), so no need to hide the Delete link in this case.

Conflicts:
	changelog.html