Added logging more liberally, and fixed the problem.
The root cause was that when the mouse enters a hot spot, I wasn't cancelling the previous delayed hide timer.

This fix eliminates the need for the hack in the hide method where I was testing if the mouse was still over the hotspot.

Using l:confirmationLink instead of AbstractItem/delete.jelly and AbstractProject/wipeOutWorkspace.jelly.

Expanded MockFolder to be a ViewGroup so that it is possible to test views inside folders,
and generally fixed it to service Stapler hierarchies properly so that WebClient-based tests can work.

[FIXED JENKINS-15340] Ask for confirmation before reloading config from disk, as it may be expensive.
First of all, /reload should require POST (also prevents XSS DoS attacks).
Adding <l:confirmationLink> to encapsulate a link that requires confirmation upon clicking.
Allowing a ManagementLink to request confirmation (also implying POST); could be used also for e.g. /quietDown.
Enhancing <l:task> to support confirmation as well, and honoring this in context menu items.

(Not touching the icon since I do not feel like playing with Inkscape; would be a nice pull request for somebody.)

Revert "[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only."

This reverts commit 3a6de84f.
(Regressed JENKINS-15666.)
Conflicts:

	changelog.html

This changes introduces a 'recurse' option on ListView that allows to
match using regexp jobs contained inside folders.
The full name of the
job is matched so / can be used as separator.
This allows slice and dice of jobs contained in different folders.

[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only.

Root cause seems to be broken serial form of FingerprintAction, probably caused by lazy loading.

Also provide proper overrides of ParameterValue.getShortDescription, rather than delegating to toString.

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

[FIXED JENKINS-7970] JUnit result archiver should only fail builds if there are really no results - i.e. also no skipped tests.

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.

[FIXED JENKINS-7291] Permit flyweight tasks to run on master even when it has zero configured executors.

Always adding Computer for master as a fallback

The original proposed fix for JENKINS-7291 creates a Computer object
transitively. This seems unwise as it violates the design of Computer
as stated in the javadoc, and for example we can end up creating two
Computers for the master.

I think a better fix is to create a Computer for the master all the
time, even if there's no executors configured. The discrimination in
Queue.makeBuildable would ensure that such phantom Computer is only used
as a last resort (statistically speaking).

I've also tweaked executors.jelly a bit. I simplified it somewhat
based on the idea that "if there's only one computer to show, the
context is likely making it obvious".

(I must be missing the intricacy in the current code.)

Originally developed in a branch at
2c5b57fcc1f39ed39057254e802f4183db5aa0dc then squashed for clarity.

[FIXED JENKINS-17331] PerJobLocalRepositoryLocator should prefer the MavenModuleSetBuild.workspace for single-module builds.