Persist trigger configuration key in related banks

From a discussion in !2259 (merged) with @graven:

as I'm getting paranoid: when running from a TCK, we know that the configuration of the ANNSvc is preserved. But what in case it isn't configured through a TCK? Maybe we should allow for a way to store the equivalent of a TCK, namely the 'hash' of the configuration of the ANNSvc as 'header' in the report, so that it can be checked that when reading back the data it is consistent, independent of how the ANNSvc got configured -- i.e. make this check explicit instead of implicit. It would require that the IANNSvc gets one more method, which is to return a hash of its table of name<->number mapping. So this is beyond this MR, and this discussion could/should be resolved into an issue....

To (try to) summarise: some representation of the TCK should be stored in each raw bank that requires a TCK for decoding. Examples are the HLT DecReports and SelReports banks, which are serialised by replacing line names with IDs stored in the HltANNSvc. Deserialising these banks correctly means configuring the service in the same manner as during serialisation, and we can check this explicitly by putting some sort of hash of the trigger configuration (or at least the ANN service configuration) in the raw bank itself.

This type of consideration applies to anything which requires knowledge of the configuration/ANNSvc for serialisation/deserialisation, e.g. in Run 2 this includes the Turbo persistency mechanism.