RichDetailedTrSegMakerFromTracks - Disable by default CreateMissingStates

This MR changes the default setting of the RichDetailedTrSegMakerFromTracks property CreateMissingStates from True to False.

I added this option a while back to handle the case of running the RICH reconstruction from DSTs, where the tracking is not run and the Track states needed by the RICH may have been stripped prior to being made persistent. This option is very slow, and never intended for 'production' processing. It was really just a convenience for the RICH group where we tend to do this a lot during development.

The issue is this option is being triggered whenever the vectorfit is used by Brunel. This is because this fitter is not creating the full list of track states as required (expected) by the subsequent processing steps in Brunel. The above workaround for the RICH is thus kicking in, silently, and creating the states on the fly. This means the RICH is about 10 times slower than it should be... @sstahl first noticed this when he tried using the vectorfit in HLT2 earlier on this year and saw the excessive slowdown of the RICH.

This MR does three main things :—

1. I turn off by default the above protection, to create the states on the fly.
2. I only enabled this if the InputType is set to be a DST type, as this is the only scenario the workaround should be used. (An MR for Brunel will follow to propagate the required information. See Brunel!415 (merged) .)
3. I have added a number of Warnings to make it clear when the protection is being used and when track states are failed to be found (i.e. when the protection is off but it was previously kicking in).

This will have an impact on some of the QM tests :-

1. The 'repro' tests will have some additional warnings indicating the workaround is kicking in.
2. The vectorfit tests will have warnings saying the RICH is failing to find the required track states (and thus not correctly processing).

You can see examples of these tests at

http://www.hep.phy.cam.ac.uk/~jonesc/lhcb/QMTests/Saved/REC-MR1050/

(There are other unrelated diffs, just ignore these...)

1. This is an expected modification to the logs, so the refs should just be updated.
2. In my view is a correct error, as its a consequence of the fact the vectorfit is not creating the correct lists of states. So the fix here should, I would suggest, not be to update the refs but instead fix the vectorfit configuration. @dcampora is aware of this issue.

In the longer term a discussion needs to be had, in the context of a future Upgrade Track class, as to how these various states as required by downstream processing steps are handled. This MR does not preclude this, but really just makes the current situation more transparent.