Noting that there is a potentially valid argument for allowing this method to work without the singleton...

- But the type of tests here would be very restricted in what they could safely do anyway, so they would largely be restricted to verifying data migration during xml loading

- It is never too late to do the right thing.
- The vast majority of usages of `Jenkins.getInstance()` in core currently assume that its return value is non-null
- This commit changes those that are written to correctly check for non-null values will call `Jenkins.getInstanceOrNull()`
- We deprecate the `Jenkins.getActiveInstance()` madness
- I checked with @kohsuke who said not to bother with a PR and just commit this strongly opinionated change direct to master as a PR will just degrade into a bikeshedding.

If a job is renamed to a string with trailing whitespace, exceptions are
thrown as the application attempts to rename the job directory in the
file system, and the job can be neither deleted nor renamed again
through the UI. This problem occurs only when renaming a job, and not
when initially creating a job, because job names are trimmed when first
created.  This change trims the job name for rename operations as well,
so that the name-setting behavior is consistent across create/update
operations and inadvertent leading/trailing whitespace is removed before
it can cause problems.

#1406 silently skipped the call to moveDirectory in case newBuildDir.isDirectory(), rather than throwing an IOE as renameTo does.
Also deleting apparently useless call to forceMkdir.

(cherry picked from commit 9b3f4885)

Conflicts:
	changelog.html

Also sending the exception to the log, which is where plugin developers expect to see it.
(This is also necessary for the exception to be visible say from configRoundtrip in a functional test.
Otherwise you just see a FailingHttpStatusCodeException due to the 400 error code, with no details.)
Might actually suffice to just throw a ServletException wrapping the exception up the chain,
letting Stapler or the container handle it, but this change is more conservative.

Pulling doChildrenContextMenu up from AbstractProject into Job, since the latter already defines permalinks.

Moved configuration of keepDependencies into AbstractProject/configure-common.jelly, since it is not a property of Fingerprinter.

Undeprecating Job.getBuild, since this is the only way to look up a build by ID if you are unsure what kind of Job it is.

Null check the 'properties' element of the json message before attempting to 'rebuild' the 'DescribableList'

Cf.: https://github.com/jenkinsci/subversion-plugin/pull/83

java.lang.NullPointerException
	at hudson.model.Job.getBuildDir(Job.java:790)
	at hudson.model.Run.getRootDir(Run.java:993)
	at hudson.model.Run.getLogFile(Run.java:1306)
	at hudson.model.Run.execute(Run.java:1664)
	at hudson.maven.MavenBuild.access$900(MavenBuild.java:94)
	at hudson.maven.MavenBuild$ProxyImpl2.close(MavenBuild.java:636)
	at hudson.maven.AbstractMavenBuilder.end(AbstractMavenBuilder.java:106)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:839)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:523)
	at hudson.model.Run.execute(Run.java:1688)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)
java.lang.NullPointerException
	at hudson.model.BuildStepListener.all(BuildStepListener.java:31)
	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:739)
	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:714)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.cleanUp(MavenModuleSetBuild.java:1054)
	at hudson.model.Run.execute(Run.java:1733)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)

[FIX JENKINS-21303] There is a NPE here that can and does happen for real when an aggresive slave retention strategy interacts with post build triggers that want to do token macro expansion

unbuildable project.

Added a new overloaded version that works on a project.

Updated CoreEnvironmentContributor accordingly.

Loading the last 3 successful builds may be very expensive in certain rare, but possible situations (all newer builds failed, only some very old builds were successful).
Go only up to 6 build into the past for calculating the estimated duration.
Also take failed builds into account, if we don't find any successful ones.

- Fixes a regression in core where the display name clear on copy was triggering a save
- More than one way to do this, could also have used the marker interface approach
  This route seems slightly less fragile, though people could still add ItemListeners
  with order == -Double.MAX_VALUE which would then introduce intdeterminism.
  A marker interface would remove that indeterminism as the onCopyComplete method would
  be only called on the Job as the last method... but it could be hard to
  ensure that all ItemGroupMixin's respect the calling of onCopyComplete contract
  hence this approach seems better to me for that reason

Report 100 recent builds in the JSON API, including in-progress builds.

Not reporting all the builds since this would nullify the lazy loading
effect. Will introduce a pagenation API that supports retrieval.

Based on comments from Jesse, revising the fix.

I'm now putting permlinks inside the builds/ directory to avoid the computing hassle involved in the split $JENKINS_HOME.

What we historically had in $JENKINS_HOME/jobs/JOB/lastSuccessfulBuild is also now subsumed by this feature. I initially attempted to create these permalinks in the buidl root directory, but turns out those symlinks aren't the same name as the ID of permalinks, so it doesn't mesh well.

And finally, a test!