FPGATrackSim: rewrite matrix gen algorithm to use road-finding for hit selection

Previously we would first filter the hits that matched a truth track according to some internal rules. This commit changes things so that instead we do not do this; we just pass the barcode-matched hits immediately to pattern recognition after mapping them. Then, we use a version of the "road to track" code to produce track combinations if we are running the first stage; if we're running the second stage we run the full track fit (though this part doesn't really work yet, that will need updating in a future MR). The hits on the track combinations then get used to fill the accumulator.

This is effectively needed to make the matrix generation algorithm work with the new version of the genscan/inside-out pattern recognition algorithm which has its own logic for assigning hits to layers.

To facilitate this I had to do a few things:

• Adapt the first part of TrackFitter's "fit tracks" function (the piece that does the "Road to track" step of building track candidates) into a new method in MatrixGenAlgo. Unfortunately we can't reuse the track fitter infrastructure directly without providing fit constant banks, which don't exist when you are running MatrixGenAlgo as this is the algorithm that generates fit constant banks.
• Modify FPGATrackSimRegionMap::isInRegion to always test if hits fall within a region by using the real physical layer rather than the logical layer; we can't trust anymore that a hit's logical layer (as determined in the plane map) is "correct" after passing hits through the binning code (used in the GenScan pattern recognition).
• Make sure the event selection service is initialized properly in both the matrix generation and constant generation algorithms
• Use the event selection service in matrix generation to veto any truth tracks that don't pass the truth selection for a given region; this prevents a lot of warnings/messages from the genscan monitoring tool and should also make things run much faster.

This needs some more testing, but it successfully generated a region 34 bank from a single all-eta RDO with multiple sectors with the following script:

export CALIBPATH=/cvmfs/atlas-nightlies.cern.ch/repo/data/data-art/PhaseIIUpgrade/EFTracking/ATLAS-P2-RUN4-03-00-00/:$CALIBPATH

mkdir -p test
rm -rf test/*
cd test/

# Map directory
MAPS="/data/lipeles/eftrack/maps/v0.20_genscan/"

# Testing for region 34; this is a random all-eta RDO file.
INFILE="/data/jahreda/reco_new/batch_alleta/output.rdo.000000.290.root"

python -m FPGATrackSimBankGen.FPGATrackSimBankGenConfig \
          --evtMax=-1 \
          --filesInput=$INFILE \
          Trigger.FPGATrackSim.mapsDir=${MAPS} \
          Trigger.FPGATrackSim.region=34 \
          Trigger.FPGATrackSim.GenScan.layerMapFile=/data/lipeles/eftrack/maps/v0.20_genscan/lyrmap.json \
          Trigger.FPGATrackSim.Hough.genScan=True \
          Trigger.FPGATrackSim.oldRegionDefs=False \
          Trigger.FPGATrackSim.GenScan.noCuts=False \
          Trigger.FPGATrackSim.msgLimit=10000000

python -m FPGATrackSimBankGen.FPGATrackSimBankConstGenConfig \
    Trigger.FPGATrackSim.FPGATrackSimMatrixFileRegEx='./matrix.root' \
    Trigger.FPGATrackSim.mapsDir=${MAPS} \
    Trigger.FPGATrackSim.region=34 \
    Trigger.FPGATrackSim.oldRegionDefs=False \
    --evtMax=1

CC @jsurduto, @lipeles, @jahreda