bring measurements back to trajectory

[ShujieL]

Briefly, what does this PR introduce?

Move measurements from Track (which is introduced in #58) back to Trajectory, and add back outliers.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• [x ] Other: partially revert a change

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• [x ] Changes have been communicated to collaborators. -- This change is communicated to Joe Osborn.

Does this PR introduce breaking changes? What changes might users need to make to their code?

CKFtracking.cc needs to be updated to take the new data structure.

Does this PR change default behavior?

[wdconinc]

We discussed this in Joe's talk. We don't want these hits in trajectory.

[osbornjd]

Shujie discussed with me offline and wanted this because (correct me if I'm wrong)

1. It may be confusing to users who use this
2. The differentiation between outlier measurements and track measurements is needed, even though outliers are a subset of the total measurements that belong to a track. Acts determines what a track state looks like with a flag (basically an enum) that labels it as measurement, outlier, hole, whatever. In principle doing something like this would consolidate the information.

I still personally think we should have the measurements in the Track object because analyzers may want to know how many measurements are on a track for quality cuts (e.g. if an analysis requires the best momentum resolution possible, require more measurements on the track). The point of differentiating between Track and Trajectory was to separate expert from user information, so that is why I put the measurement list in the Track object.

[wdconinc]

Shujie discussed with me offline and wanted this because

Whatever it is, let's try to get this right in fewer steps, ok? I.e. this better be the final one.

[osbornjd]

I don't have an issue with this, my opinion is that the measurements belong in the Track object as analyzers may want to know how many exist on a track (and how many from various subsystems exist), and if we are trying to keep analyzer info from expert info separate then this should be moved. But I'm not going to argue for it if others think it is better in this proposed way

[ShujieL]

I noticed this PR is still open.
The "Track" data structure is not used anywhere in EICrecon. All ongoing analysis access measurements etc from "Trajectory" with the previous tagged version. To be consistent, can we keep this trajectory structure unchanged (i.e. bring the references to hits back as I suggested in this PR). We can always change this when future algorithm development with "Track" is ready.
@wdconinc @osbornjd

[wdconinc]

The "Track" data structure is not used anywhere in EICrecon.

I think we(you) should address that issue instead of reverting data model changes.

[osbornjd]

It's fine to merge this to maintain current functionality IMO but it should not be used as an excuse to punt the switch to Track further down the road. The longer it takes the more entrenched analysis will be in the current scheme which is not maintainable long term...