[JENKINS-33467] Do not store duplicate Cause’s

Use getInstance() in place of getInstanceOrNull() for execution paths that cannot have a null

The `@Initializer` and `@Terminator` annotated methods are only executed where `Jenkins.getInstance()!=null`

Fix Jenkins.getInstance() to make life easier for plugin authors

Revert JENKINS-32190 fix

[FIXED JENKINS-33425] Refactored the cleanUp() method to log progress and push for completion

Revert "[JENKINS-32190] Make UsageStatistics#isDue check Jenkins init level before generating stats."

This reverts commit d8a13ac0.

I noticed a strange drop in usage statistics from the mid Jan 2016,
which corresponds to the time this change was released in the wild,
and further drop when LTS 1.642.2 is released with this change at
the end of Feb.

I spent some time trying to determine how this might cause instances
to stop sending data, but I couldn't come up with any. I left those
notes in JENKINS-32190. There was some strange behaviours, but none
explains what this is.

So I'd like to back out this change and see if that makes any impact
on the stats collection. If it backs up, then we know empirically
this change is to blame, so that would justify spending further
effort or come up with a fix from a different angle.

[JENKINS-33414] Ensure that the tests do not leave the JVM marker flag set

[FIXED JENKINS-26580] Activate JNLP3 support

[FIXED JENKINS-33414] Added an API to allow identification of the Jenkins JVM

[FIXED JENKINS-33384] clean up the PluginServletFilter instances on Jenkins.cleanUp()

- Fix the ProxyConfiguration code to not require Jenkins class to be loaded in remote JVMs

- Code that is running from a plugin and on the master's JVM is guaranteed to never get null from this method (any cases where you do get null are bugs in core)
- Code that is running from a plugin and on a remote JVM should never be allowed to load the Jenkins class in their classloader, so should never use Jenkins.getInstance()... we are annotating the method with @Nullable so that such code can have some evolution time
- Code that is running in core and on one of two special paths should use the Jenkins.getInstanceOrNull() method so that the UI can be presented to users before the singleton has been instantiated / after the singleton has been destroyed
- The remaining 95% of uses in core (and 100% of uses in plugins) can safely assume that the instance is never null

This reverts commit bb7c8fce.

Closes #2090, I'll redo this as a PR... though if that PR is subject to multiple rounds of review before being merged then I will take that of evidence of the exact problem that committing directly was supposed to resolve... namely exponentially multiplying the effort required to make actual improvements to the code base.

[FIX JENKINS-28790] Masked parameters are now hidden on Windows

[FIXED JENKINS-33377] Add a check for termination to Functions.isExtensionsAvailable()

- Only ever called after extensions are on the classpath and before termination

- Only ever called after extensions are on the classpath and before termination

- Only ever called after extensions are on the classpath and before termination
- If it were somehow or other called after `Jenkins.theInstance == null` then at that point the queue has already been persisted so the trigger could have no effect anyway... much better to surface in the shutdown logs about the missed trigger than either return false or incorrectly report the job as triggered

- Only ever called after extensions are on the classpath and before termination

- Only ever called after extensions are on the classpath and before termination

It would be better if we had an explicit method to identify when code is run in a thread on the master vs in a thread on a slave

 - because forcing the slave to load the Jenkins class into its classloader is probably not a good plan