updated German translation

I think this is an oversight in bded790f. 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.

[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome() 

Fix changelog generation in ExtractResourceWithChangesSCM

Break links inside pre tags

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.

[JENKINS-18065] 54c08461 amendment: presumably RunMap.entrySet().iterator().next().setValue(…) should be illegal.

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.

[JENKINS-22395] Taking advantage of BuildReference.clear (just introduced in b6226ad2) 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.)

Just in case the previous fix didn't address the root cause of ZD-11985 (and given the time it takes for changes like this to land in LTS), I'm adding additional diagnostics that let us track how previous/next builds are getting discovered

Based on the last few commits, I proved that the original fix in f1430a25
doesn't really address the problem.

That is, once b2 is deleted, and after sufficient garbage collection,
we can make b2.previousBuild.get() be null, and then
b2.getPreviousBuild().getNextBuild() ends up incorrectly returning b2.

In this commit, I roll back that part of f1430a25, and then fix the
problem differently.

I started thinking that the main problem we are trying to fix here
is that the deleted build object should be unreferenceable. That is,
it should behave almost as if the object has already been GCed.
The easiest way to do this is to clear a BuildReference object,
since we always use the same BuildReference object for all inbound
references.

This change allows us to clear BuildReference. Code like
b2.getPreviousBuild() will continue to try to update
b1.nextBuildR to b2, but it will only end up wiping out the field,
only to have b1.getNextBuild() recompute the correct value.

This fix makes both test cases pass in LazyBuildMixInTest.

As I step-executed the code, I discovered b2.getPreviousBuild() was getting invoked
between BRHF.drop(b1) and b2.dropLinks() call, in PeepholePermalink.RunListenerImpl.onDeleted()
because Run.delete() calls RunListener.fireDeleted(this).

Thus in effect the sequence of the call order was as follows:

        assertEquals(1, BRHF.drop(b1));
        b2.getPreviousBuild(); // happens indirectly in PeepholePermalink
        b2.delete();
        FreeStyleBuild b1a = b2.getPreviousBuild();

This defeats the purpose of the fix, because in this call sequence, by b2.dropLinks()
as implemented before f1430a25 will correctly fix up b1a.nextBuildR to b3.

For the test to work as intended, it is important that b2.previousBuildR.get()==null
during dropLinks(). That is what causes b2.getPreviousBuild() in the next line to go
load b1a, and sets up b1a.nextBuildR to b2, and trigger the assertion error.

Added a code to remove all RunListeners. With this change, the test now fails without
the fix in f1430a25.

I'm not sure if I understand how the original fix in PR #1190 (f1430a25) addresses the problem.

My understanding is of the problem is as follows:

  - someone deletes 'b2' but holds on to its reference (could be different threads)
  - someone calls b2.getPreviousBuild()
    - if b2.previousBuildR is null, then this triggers the loading of b1, and
      that process sets up a bi-di link via b1<->b2 via b1.nextBuildR <-> b2.previousBuildR
    - this makes b1.getNextBuild() incorrectly return b2

Presumably f1430a25 addresses this somehow, but I think I can induce this situation in other ways,
which is what dropLinksAfterGC2() does.

In this test,

initial state:

   b1 <-> b2 <-> b3

   we load everyone and connect them all up

after deleting b2:

   b1 <--------> b3
    ^            ^
    +---- b2 ----+

  b1 and b3 points each other, and b2 still refers to each side

after dropping b1:

          b2 --> b3

now, here, when I do b2.getPreviousBuild(), it loads b1a and it sets b1a.nextBuildR to b2.

    b1a <-> b2 --> b3

So I claim this is a proof that the fix is incomplete, even for the problem JENKINS-22395 has discovered.

I don't think that the problem is for the dropLinks call to fail to patch up references.
The problem is that b2.getPreviousBuild() forcing b1 to point to b2, because if b2 is deleted and assumed to be
invalid, then no matter what bX this method will find you never want bX.nextBuildR to point to b2.

Switch underline/non underline on sidebar

The underline adds slightly too much visual weight to the links in question.
This changes the links to not have an underline by default, while still adding
the underline when the link is hovered.

Normally accessibility requirements demand that you add an underline for all
clickable text. However, in this case the positioning of the elements, their
changed color, the presence of an icon next to the links, and the link hover
effect combine to give these elements the appearance of clickability.

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.

WARNING: Caught exception evaluating: e.hasStopPermission() in /. Reason: java.lang.NullPointerException
java.lang.NullPointerException
	at hudson.model.Executor.hasStopPermission(Executor.java:523)