updates German translation

Since 'Job' was renamed to 'Item', this translation should be updated
Update sidepanel_de.properties
Update newJob_de.properties
[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome()

There appears to be some unthreadsafe initialization going on here.
Initialize/get inside a synchronized block for threadsaftey.
Fix changelog generation in ExtractResourceWithChangesSCM
when several files are changed at once
(used in the fix for JENKINS-22622)
Update newJob_de.properties
Break links inside pre tags

to prevent page from horizontal scrolling.
Update style.css
[JENKINS-22395] Taking advantage of BuildReference.clear (just introduced in b6226ad) to simplify test by not requiring a custom build reference holder just to simulate GC.
Confirmed that dropLinksAfterGC and dropLinksAfterGC2 both fail in the expected way (b1a.nextBuild == b2) after commenting out the call to createReference().clear() in dropLinks.
(Also that they fail as expected in assertNotSame if the reference is not cleared at all.)
Line up elements in the left side

Now you can draw a straight vertical line and see that the logo image, the
beginning breadcrumb, and the build history are all in a straight line.
[FIXED JENKINS-18065] made ALLRM.entrySet() smarter
Reverting apparently unintentional change from 54c0846.
[JENKINS-18065] 54c0846 amendment: presumably RunMap.entrySet().iterator().next().setValue(…) should be illegal.
[JENKINS-18065] Uncommenting original test.
The actual implementation does not behave as nicely as one would hope, for a few reasons:
1. isEmpty actually tries to load the newestBuild, rather than simply checking whether there is some idOnDisk.
   Arguably this is necessary, since there could be an unloadable build record, in which case it would be technically correct for the map to be considered empty.
2. Loading AbstractLazyLoadRunMap.newestBuild calls search(MAX_VALUE, DESC), which behaves oddly, by doing a binary search, and thus perhaps loading lg(|map|) entries.
   You would think that it would suffice to check for the last member of idOnDisk in index.byId.
3. The iterator eagerly loads the next value before hasNext has even been called.
   Looks bad in a test, though it probably has little practical impact since most callers would be calling hasNext soon afterward anyway.
   Might cause one extra build record to be loaded unnecessarily from a limited RunList.
Merge pull request #1308 from Simek/patch-1

Break links inside pre tags
Merge REMERGE_HEAD into HEAD
Merge pull request #1189 from jeanblanchard/master

Fix changelog generation in ExtractResourceWithChangesSCM
Merge pull request #1176 from jkolash/master

[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome()
Bundling the latest
[ZD-19640] diagnostic improvement in case impersonation failed.

I think this is an oversight in bded790f4651459b2ac41d9f96f2393204b41012. A random attacker wouldn't know the correct API token value,
so given that it matched, I think the caller should know that it was the impersonation that failed, not the authentication.

Also log this at a higher level, since this indicates a problem in SecurityRealm.