Accomplished by centralizing calls to System.getProperty(String) and related into new file SystemProperties.java.
There, we first check for existence of system property; if not, we look for property in context.xml
This is done for "application" properties (like hudson.DNSMultiCast.disabled) but not for java properties (like user.name)

Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

The change adds annotations for all methods inside the class. The initial idea - enforce checks of symlink methods to prevent NPEs on Windows platforms.
Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

Retrying 3 times while waiting for 100 millis between retries (at
recreating symlink after "deleting" it). Ends up throwing FAE exception
if thrown for a 4th time in a row - as not much can be done at that
point. A warning is logged in that case, prior to throwing the last FAE.

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.