[FIXED JENKINS-4433] Explicitly set log4j version to 1.2.17.

Grammer fix

AbstractScmTagAction.getBuild is deprecated in favor of getRun

AbstractScmTagAction.getBuild is deprecated in favor of getRun; Jelly views should be updated accordingly.

[JENKINS-27436] Fix button link appearance

Added warning flag to shebang line, corrected string formatting, minor spelling and grammar fixes

[JENKINS-22028] update label to reflect actual behavior

Added warning flag to shebang line, corrected string formatting, minor spelling and grammar fixes to comments.

[JENKINS-2180] Always use earlier scheduling date.

[FIXED JENKINS-28926] Block while upstream/downstream building cycles never complete

- I was forgetting the call to `rebuildDependencyGraph()` which was why the test didn't work for me

- One could argue that without this change the system is functioning correctly and that previous behaviour
  was a bug. On the other hand, people have come to rely on the previous behaviour.
- The issue really centeres around state changes in the blocked tasks. Since blocking on upstream/downstream
  relies on checking the building projects and the queued (excluding blocked) tasks we need any change in
  the blocked task list to be visible immediately (i.e. update the snapshot)
- I was able to reliably reproduce this behaviour with a convoluted set of manually configured projects
  but turning this into a test case has not proved quite as easy. Manual testing confirms that the issue is
  fixed for my manual test case
- I have also added a sorting of the blocked list when probing for tasks to unblock. This should prioritise
  tasks as intended by the QueueSorter

ExtractResourceWithChangesSCM now needs to have a descriptor

Expose the type information for people's JavaScript

Prerequisite for JENKINS-25785

Contine the JENKINS-27289 ticket: update the getResources as well

[JENKINS-4433] Add log4j to dependency management section, exclude it for acegi-security dependency.

[FIXED JENKINS-28840] Deadlock between Queue.maintain and Executor.interrupt

- I suspect the synchronization on Jenkins is a bug also... but not causing the test failure, so will ignore for now

Otherwise you get:
java.lang.AssertionError: class org.jvnet.hudson.test.ExtractResourceWithChangesSCM is missing its descriptor
	at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1166)
	at hudson.scm.SCM.getDescriptor(SCM.java:654)
	at hudson.scm.AutoBrowserHolder.get(AutoBrowserHolder.java:54)
	at hudson.scm.SCM.getEffectiveBrowser(SCM.java:136)
	at hudson.scm.ChangeLogSet.browserFromBuild(ChangeLogSet.java:82)
	at hudson.scm.ChangeLogSet.<init>(ChangeLogSet.java:76)
	at org.jvnet.hudson.test.ExtractChangeLogSet.<init>(ExtractChangeLogSet.java:41)
	at org.jvnet.hudson.test.ExtractChangeLogParser.parse(ExtractChangeLogParser.java:80)
	at org.jvnet.hudson.test.ExtractChangeLogParser.parse(ExtractChangeLogParser.java:52)
	at org.jvnet.hudson.test.ExtractChangeLogParser.parse(ExtractChangeLogParser.java:46)
	at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:894)
	at hudson.model.AbstractBuild.access$600(AbstractBuild.java:104)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:634)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
	at hudson.model.Run.execute(Run.java:1745)
	at …

For people doing JavaScript based page manipulation from JavaScript for
quick UI hack/prototyping, information about what the page is about is
useful, even if it's not completely reliable (e.g., the top page
reporting it's for AllView not for Hudson)

[FIXED JENKINS-28601] Revert "[FIXED JENKINS-17290] -  Corrected sort order of tables"

More fun here:

- All this originates from Executor extending Thread.
- There is funky logic in the lock handling code of the JVM that makes assumptions
  about how it might proceed with the lock when the thread holding the lock has its
  interrupt flag set.
- Really it would be better if Executor did not extend Thread as that way we wouldn't
  have to deal with some of that complexity. But OTOH we are where we are and backwards
  compatibility may make such a change not possible without a lot of breakage.
- Fixing the issue at hand, firstly requires that interrupting a Computer happens with the
  Queue lock held (to speed up tests we have Jenkins.cleanup get the lock for all Computers)
  That prevents the Queue maintain thread from getting caught
- Secondly, when removing an executor from a computer we process the removal while
  holding the Queue lock, but we move the removal itself to a separate thread if we cannot
  get the Queue lock in order to avoid deadlock.
- Also add helper methods to wrap tasks to be performed while holding the lock
  and a helper method for Runnables that exposes the tryLock functionality

This reverts commit d739bedc.

Prerequisite for JENKINS-25785 in order to break dependency cycle when windows-slaves will depend on credentials