Multithreaded JobReport

Fix a comment
Add std::memory_order_acq_rel to exhcage methods; fix memory leak
Add memory order parameters
Add MeasurementTrackerEvent producer  in cosmic sequence (fix runTheMatrix workflow 1000.0)
Add memory order; Re-align code blocks
Merge pull request #914 from ianna/geometry-validation

Geometry bugfix -- Fix scripts to run geometry validation
updateHIstrings
some changes were accidentally overwritten at merge
Ecal fixes -- Get 101.0 and 102.0 back to work.
Tests of cache types for EDProducer, EDAnalyzer and EDFilter in the edm::global,edm::stream and edm::one namespaces
Merge pull request #919 from ktf/fix-missing-interestingDetIdCollections

Ecal fixes -- Get 101.0 and 102.0 back to work.
HistoryAppender no longer uses ProcessHistoryRegistry

To allow for thread-safe uses of the ProcessHistoryRegistry, the HistoryAppender no longer updates the ProcessHistoryRegistry to hold its appended history. Now it just returns a shared_ptr to the new or cached ProcessHistory. The shared_ptr is now owned by all Principals which are currently processing with that history.
To simplify the sharing, we only cache the last ProcessHistory and no longer hold a map to all previously seen histories. This will allow us to have one HistoryAppender per Stream when used by the SubProcess.
Updated to match new HistoryAppender API

The HistoryAppender now returns a shared_ptr<ProcessHistory const> so processHistoryPtr_ was changed to match. In addition, the fillPrincipal function no longer needs to modify the ProcessHistoryRegistry so the argument is now const.
fill*Principal method no longer modifies the ProcessHistoryRegistry.

The underlying Principal::fillPrincipal no longer modifies the ProcessHistoryRegistry and therefore takes a const reference. The fill*Principal methods were updated to match. This makes it clearer when reasoning about thread safety.
RunPrincipal::fillRunPrincipal no longer modifies the ProcessHistoryRegistry and RunPrincipal now holds the reducedProcessHistoryID

-Principal::fillPrincipal no longer modifies the ProcessHistoryRegistry so now takes a const argument. fillRunPrincipal was updated to match.
-The RunPrincipal now holds onto the reducedProcessHistoryID which is used to uniquely identify a Run. This makes identification of a Run easier for the SubProcess when it is time to write that Run.
SubProcess has own copy of ProcessHistoryRegistry

Now has its own copy of the ProcessHistoryRegistry as preparation for thread-safety. As part of the change, now get the parent’s reducedProcessHistoryID from the RunPrincipal and not from the parent ProcessHistoryRegistry (which is no longer accessible).
Full thread-safety will require each Stream to have its own ProcessHistoryRegistry and HistoryAppender.
EventPrcocessor uses new SubProcess constructor and reducedProcessHistory from RunPrincipal

The SubProcess no longer takes a ProcessHistoryRegistry as an argument to its constructor since it now has its own internal copy. This avoids possible updates of a ProcessHistoryRegistry from different threads.
In addition, RunPrincipal now holds its reducedProcessHistoryID so the EventProcessor now uses it from the RunPrincipal and not the Source.
Pass const ProcessHistoryRegistry to fill*Principal

The various fill*Principal member functions were changed to take a const ProcessHistoryRegistry. This change just swaps out using processHistoryRegistryForUpdate() and now use processHistoryRegistry() to make it clear that no change is required.
another missed access fix
hcal data accesss fix to DataMixing stuff