[JENKINS-31618] Fixed NoSuchMethodException in loginLink.jelly

BuildProcess: Update animal-sniffer-maven-plugin from 1.9 to 1.15.

[JENKINS-34767] - Prevent RSS ID collisions for items with same name in different folders

* [JENKINS-25164] Add SHORT_JOB_NAME env var

* Delete strip off

* [JENKINS-25164] Change SHORT_JOB_NAME for LEAF_JOB_NAME

* [JENKINS-25164] Change LEAF_JOB_NAME for JOB_BASE_NAME

Diff: https://github.com/jenkinsci/lib-annotation-indexer/compare/e90dade9a07b04b64ac1b08d539d30ad69ddf7a8...2eec43c72b3cd040d2057e6bbbf639f5e030453e

Major changes:
* 1.11 - [JENKINS-32978] support latest source version to avoid compile time warnings with JDK7
* 1.10 - Get ready for JDK 9
* 1.10 - Be tolerant against line separators on different operating systems
* 1.9 - Support of third-party annotations
* 1.8 - Annotation processor can be intercepted

The logic is moved from template back to Java and modified to fix the issue.
The argorithm is rewritten for better legibility.

[JENKINS-32777] Cover 'delete-builds' CLI by tests

Conflicts:
	changelog.html

Slighty optimized and better legible asserts

[JENKINS-34710] - PluginWrapper should not throw IOException if somebody enables the enabled plugin (#2327)

* Remove CVS historical code - JENKINS-4610

* Fix whitespace issue

reload-configuration covered by test-cases

More details: https://issues.jboss.org/browse/WFLY-4782

see http://stackoverflow.com/questions/8185331/forward-compatible-java-6-annotation-processor-and-supportedsourceversion

[JENKINS-34674,JENKINS-34675] - Handling of the default update site ID

As detailed by @stephenc:

> So there is `getInstanceOrNull()` which is for use in Jenkins core or
> in code that plugins add that may escape the Jenkins singleton
> lifecycle.
>
> In regular plugins `getInstance()` will never return null as the
> lifecycle does not instantiate them until after there is a Jenkins
> singleton and the plugins will be stopped before there is no
> singleton.
>
> The `getActiveInstance()` is therefore equivalent to `getInstance()`
> and should never have been born.
>
> The only way a plugin can get a `null` from `Jenkins.getInstance()` is
> if you install an `atExit()` handler, use a `PhantomReference` type
> thing, or directly manipulate the servlet container in some way or
> other. A correctly written plugin should unwind any of those things
> when it is stopped or a method bound to the termination lifecycle. If
> there are some cases (for which I cannot anticipate a good coder being
> able to write a correct termination lifecycle method to fix) where the
> code cannot be unhooked... then in those cases the plugin should use
> `getInstanceOrNull()` and know how to respond to the `null` that could
> not be avoided.

[JENKINS-34328] CLI command disconnect-node extracted from core to CLI

[JENKINS-34683] - Do not print stack trace if plugin is missing dependencies

Workflow users may want to catch specific Exceptions without stracktrace in future.