[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

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

Fix some loggers which are identifying as the wrong class.

[JENKINS-28292] fixed synchronization issue when setting JDK installations

[JENKINS-25734] - Prevent NPE in Executor/causeOfDeath page on "expected thread death"

[FIX JENKINS-14899] Don't use truncating LargeText for /consoleText

Update FindBugs annotation library and maven plugin

PluginAutomaticTestBuilder improvements

[FIXED JENKINS-28690] Deadlock in hudson.model.Executor

NPE fix for AbstractProject polling when node is not available

[FIXED JENKINS-28041] - Allow delete-* CLI commands to operate on multiple arguments

- Rather fun one here. The Lock code relies on assuming that Thread.interrupted() is clear on entry
- If it then sees Thread.interrupted() set, it will interrupt the current thread in order to set the
  flag again.
- Executor is a thread that does funky things with an overridden interrupt method
- Executor.abortResult() is used to track a build be interrupted or aborted in some other way
- As a result the abortResult can cause a deadlockif there is a genuine interruption
- This fix clears the interrupt flag in abortResult() and uses the write lock in order to ensure:
    - The same lock as used in interrupt() is helf
    - The interrupt flag is clear
- Clearing the interrupt flag should be safe as the only time it is called is immediately after
  an interruption and the resulting exception is caught and rethrown/logged anyway

The change does not fix the issue, but it suppresses NPE at least.

[FIXED JENKINS-28654] - Check null nodes condition in AbstractProject constructor

[FIX JENKINS-27739] Clear cached env vars when node goes online