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)

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

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

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

View getView(String name): checkPermission() -> hasPermission() and return NULL if the user doesn't have a READ permission

Sometimes observed at end of (passing) WorkflowTest.executorStepRestart in 1.596.1:
Exception in thread "Executor #0 for slave0 : executing PlaceholderExecutable:job/demo/1/:null" java.lang.NullPointerException
	at hudson.model.Computer.removeExecutor(Computer.java:869)
	at hudson.model.Executor.run(Executor.java:272)

Squashed commits:
[73308b5] [FIXED JENKINS-27549] job loading can be broken by a NPE in a build trigger

Before, if N nodes connected quickly, this would spawn N threads all
sleeping for 5 seconds before realizing they don't need to do anything.

Calling hash.add() in a tight loop gets very expensive. With a
good-sized queue & slave pool, this cost tens of seconds, but now it
costs tens of milliseconds.

[JENKINS-28446] - Introduce new API method in Queue to optimize the performance of UnlabeledLoadStatistics

This implementation does not create new methods in API, hence it can be backported.

Just to prevent similar misuses in the future.

Simple `<l:task post="true" href="someurl"/>` triggers post request as expected
but then proceeds to href as normal link to. If the URL accepts GET then request
is sent twice it if does not after POSTing on background user get
'POST is required' error.