LArHV: Thread-safety cleanups.

The HV manager classes here mix together two kinds of information.
There is information about the structure of the cells, which is static,
and information about the actual HV settings, which derives from conditions
data and can change.

The managers are stored in the detector store.  As originally intended,
the manager classes get updated in place when conditions change.
The actual update of the HV data is done lazily through const methods
called by the accessors.
This is not thread-friendly.  Though earlier changes ameliorated
the worst of the issues, it's still difficult to ensure that there
can't be problems (and it is problematic to get the thread-safety
checker to accept the code).

Here, we rework these classes to put these issues to rest.  The conditions
information is firmly separated from the geometry information.
The geometry information remains part of the manager classes, while
the HV information is computed on request and returned in a separate
structure.  The inputs for this are the required conditions data objects.

For compatibility with previous usage, we also continue to support constructing
HV information with no explicit inputs.  This will use the obsolete
LArCablingTool rather than the HV mapping conditions object, so these
methods are tagged as not thread-safe.  The clients for this at this time
are the G4 initialization classes, which don't have the conditions objects
available.