Given these <variable,value> mappings: <A,a> and <A.B,a-b>, $A.B would
evaluate to $a.B, as it currently does, and ${A.B} to a-b instead of the
current ${A.B}.

Existing ${A.B}-like references will break (not evaluate to ${A.B}) if
there actually is an A.B variable defined, which I think is very
unlikely.

[[JENKINS-16301] Use a buffered input stream to get somewhat better performance also from Maven archiving.
Introducing Util.getDigestOf(File) as a convenience.

[FIXED JENKINS-18178] Reverting an inessential part of the fix of JENKINS-16301 since it broke some Maven builds.
Apparently the Maven 2 process factory fails to adequately insulate the Maven process from Jenkins library dependencies;
if you specify a build extension that can override dependencies used by Jenkins core classes!
A real fix would involve changing class loader delegation, since presumably similar bugs could still occur.

[JENKINS-16301] Replace impl of getDigestOf with standard (Commons Codec) DigestUtils.md5Hex, for simplicity.

[FIXED JENKINS-17681] Do not try to call resolveSymlink on a nonexistent link as you will just get an IOException, breaking peephole permalinks in some Windows environments.

On Chrome (and possibly others), an inline element like span doesn't enlarge
its size to cover its content, so the 1px place holder wasn't taking effect.

To ensure the minimum height of 16px, make it an inline-block element. I'm
not entirely sure how an inline-block element with no fixed width would behave,
but with a bit of casual testing, the text inside seems to wrap OK.

As I mentioned in the comment, I doubt if this makes any behaviour change, but this seems like a sensible defensive measure that wouldn't hurt.

Don't break Windows XP, fall back gracefully to no-op.

- ID_FORMATTER is time zone sensitive, so comparing against # of
  milliseconds since the epoch won't be portable.

- resolveSymlink can return a relative path.

Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)

Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.

This change is originally from pull request #682.

b5ed3199 already caught linkage errors but then unconditionally returned false from Util.isSymlink, which is wrong;
we want to fall back to the generic File.canonicalPath comparisons in this case.

[JENKINS-13202] 646154f1 refinement: resolveSymlink is documented to return null, not throw an exception, when called on a regular file.

[FIXED JENKINS-15316] Harmless but noisy exception running builds on some Windows systems in non-English locale.
Falling back to just checking for ‘FileSystemException’ since detail message about missing required privilege may be translated.

(Not doing so for resolveSymlink since it would require an awkward four-way return value:
String, null (not a symlink), IOException, <something else> for Java 5/6.)

Try to use NIO.2 (Java 7) methods to work with symlinks, falling back to JNA (or worse) only on Java 5–6.

Tar/untar now correctly supports symlinks.