[FIXED JENKINS-19976] Enable plugins to load classes from optionally depending plugins even without restarting after depended ones installed.
[JENKINS-19976] Tests for the behavior of loading a depended plugin dynamically.
[JENKINS-19976] Added tests how dynamic load works for @Extension.
[JENKINS-19976] Added plugins to test dynamic loading.
Merge branch 'feature/JENKINS-19976_TestForInstallDepended' into feature/JENKINS-19976_LoadClassFromNewInstalledPlugin
[JENKINS-19976] Fixed confusing comments.
[FIXED JENKINS-19081] Offer the option of downloading metadata directly from the server.
Be a bit paranoid and ensure the admin has CONFIGURE_UPDATECENTER before turning off signature checks.
@kohsuke prefers that the option to disable signature checks not even be presented unless -Dhudson.model.DownloadService.noSignatureCheck is used.
Merge branch 'master' into DownloadSettings-JENKINS-19081

Conflicts:
	core/src/main/java/hudson/model/DownloadService.java
	core/src/main/java/hudson/model/UpdateSite.java
Testing the loadJSON method directly to make sure various JSONP formats are handled.
Deleting failing test updateDirectlyWithHtml.
loadJSON does not support parsing HTML.
Nor should it need to, since UC URLs are supposed to be to the JSONP file.
The .html extension is added automatically by downloadService when postBack is supported.
Merge branch 'master' into DownloadSettings-JENKINS-19081

Conflicts:
	test/src/test/java/hudson/model/UpdateSiteTest.java
May as well use new DownloadService.loadJSON method here.
Introduced LazyBuildMixIn.
Shuffled a line of Javadoc to its intended location.
Forgot to call LazyBuildMixIn.onLoad.
Introduced LazyLoadingJob marker interface.
1. ItemListenerImpl needs to know which items have a RunMap on which it can call updateBaseDir.
   Using reflection sort of worked for this purpose, but was messy.
2. onLoad needs to get the RunMap from a peer of the owning job.
   Reflectively calling _getRuns on the peer did not work since it may not yet have had a base dir set.
So we need a way of finding the actual mixin (or at least the RunMap) of a given job.
This is not pretty but seems preferable to injecting something into the type hierarchy between AbstractProject and Job.
No obvious reason why the specialized doDoDelete in AbstractProject could not be pulled up into AbstractItem.
Some Jelly fragments which make sense only for AbstractProject were for some reason defined in AbstractItem.