SRM: tidy up how JDC is used and how it interacts with NDC

The SRM has a class 'JDC' that has roughly the same functionality as
the cells CDC class, namely to be a container for all diagnostic
information.  Both CDC and JDC make use of the NDC class, which
provides a stack of diagnostic information in which items may be
pushed, popped, reset and the state saved and restored later on.  Also,
both use the same key-value storage: MDC.  (In fact, correct flow of
diagnostic information from SRM to dCache relies on both using MDC with
the same key, which is not clear from casual inspection.)

When a request start from within SRM it is assigned a session-ID, as
with other doors.  Like other doors, the SRM pushes the session-ID into
the NDC, so logged messages contain this useful information.  Note
that, although the stored session-ID and the string pushed into the NDC
have the same value, they are stored independently.

Unlike other doors, the SRM may alter the session-ID while processing a
request.  For example, an SRM request that may involve multiple files
will have different session-IDs when working on different files within
the same request.  The file-specific session-ID is derived from the
SRM-request session-ID by appending a counter.

Updating the stored session-ID is supported; however, NDC does not
support altering an already-stored value.

To work around this, the JDC pops the existing value and pushes a new
value.  This is fragile as it only works if no other diagnostic
information is pushed after the session-ID.

This patch updates JDC so it allows popping an arbitrary number of
items off the NDC, updating the session-ID and pushed the previously
popped items back onto the NDC.

The patch also updates JDC to make use of the try-with-resource
pattern.  Some methods that alter the diagnostic context return a JDC
object that, when closed, revert these (and any subsequent) changes.
This is similar to how CDC was updated to follow this pattern.

The SRM code is updated to make use of this new pattern; it also fixes
some places where SRMv1 code failed to set the session.

The Axis thread is updated so that the session-ID is present in logged
messages.  This is particularly useful for the srmGetStatus-family of
requests.

Finally, the patch updates the format of the session-ID.  The current
format is unnecessarily verbose.  The new format is <epoc>:<counter>,
where <epoc> is a one to three Base64 characters (i.e., from
[a-zA-Z0-9+/]) and <counter> is the number of SOAP requests since
start-up.  The <epoc> is chosen so it is very (very) likely different
between successive SRM instances.  The result is the session-ID is
noticeable shorter (initially 3--5 characters compared to 8), making
logged lines easier to read.

Target: master
Requires-notes: no
Requires-book: no