webdav: work-around race-condition in StringTemplate library

StringTemplate has a lazy-load for parsing the template file.  It
turns out that this is very racy, with at least two race-conditions.

Once race-condition has the effect that if two threads attempt to
fetch a template at about the same time with the template file not
loaded then the template being requested by the second thread (the one
that lost the race, so not loading the template file) will be never be
available.

Since dCache uses STGroupFile object to render only one template, this
means that if two threads attempt to fetch the template close enough
together then the template is never available and null is returned.
Because of another problem, this triggers a NPE.

A symptom of this problem is that dCache (> 2.6) will log a single
entry

   "redefinition of template <name>"

where <name> is the template that is no longer available.

The work-around is to force the loading and parsing the template file
by the thread creating the cell.  This removes the race-condition and
the file is loaded correctly.

There is another race-condition that results in multiple threads
attempting to load and parse the file.  This will result in dCache
logging a line like:

   "redefinition of template <name>"

for each template and for each additional thread that attempts to load
the file. While noisy, this should only happen (if at all) for "a
while" after initialising and does not affect the correctness of the
rendered response.

Target: master
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Bug-report: http://rt.dcache.org/Ticket/Display.html?id=8315
Bug-report: (private correspondance with DESY people)
Patch: http://rb.dcache.org/r/6986/
Acked-by: Gerd Behrmann

Conflicts:
	modules/dcache-webdav/src/main/java/org/dcache/webdav/DcacheResourceFactory.java
Merge pull request #542 from paulmillar/fix/2.7/stringtemplate-race

Fix/2.7/stringtemplate race