fix two logic bugs in VrtSecInclusive

This MR fixes two logic bugs in the initial stage of the VrtSecInclusive algorithm.

• Track pairs that should be rejected by the minimum d_0 criterion (at least one track is required to be above a minimum |d0|) were instead being accepted as compatible with a mutual vertex, without ever attempting a vertex fit or testing any of the other intended cuts.
• When checking for track pairs in a DV pointing back to the DV, the cut was unintentionally checking the first (in arbitrary ordering) track twice without ever testing the second.

The second bug may have beneficial features, as it resulting in a stricter requirement than originally designed. Hence, adding a new property DoTightPVcompatibility to VSI that will make it run this version of the cut (just extended to consider both tracks instead of only the first of a randomly ordered pair). This is off by default.

Will change the LLP1 derivation output, since the VrtSecInclusive algorithm is run as part of this step.

CC @jburzyns @dtrischu @akvam @cappelt @mvessell - please feel free to add anyone who may want to chime in.