[2024-patches] lbexec Kwarg to bind addNeighbouringMuonHits

Affects only the tracking efficiency muon-probe matching to long tracks. cc:

• @rowina for RTAWP4's Jpsi effs : DiMuonTrackEfficiency
• @lugrazet for electroweak's Z effs : ZTrackEfficiency
• @kmattiol for IFT's Jpsi effs : SMOG2_Jpsi_trackeff

cc @msaur

New kwarg added to production.hlt2 and changes the default behaviour back to 2024-like:

"""
trkeff_probe_matching(default="2024-like"): Binds MuonProbeToLongMatcher.addNeighbouringMuonHits. {2024-like, 2025-like}.
"""

For bookkeeping purposes, the following was decided after presenting:

• default for this MR should be 2024-like
• sibling MRs should be opened to 2025-patches and master with default=2025-like
  • [2025-patches] lbexec Kwarg to bind addNeighbou... (!5199 - merged)
  • Draft: [master] Propagate !5168 (!5200 - closed)

Context

Tag-and-probe di-muon combinations are used to evaluate tracking efficiencies in a data-driven way.
There was a new (improved) MuonOverlap criterion for the matching algorithm in these lines added in Rec!4150 (merged) + !4179 (merged).
This new MuonOverlap criterion was introduced after 2024 data-taking and is used by default in 2025 data-taking (since !4179 (merged)).
As this only affects Matching criteria of the tag-and-probe, the improved matching can be used to evaluate 2024 data by rerunning HLT2 over the already processed data.
To enable this, the option was back-ported to several 2024-releases, and with it the default choice added !4179 (merged).
However this reprocessing comes with a risk, as it's necessary to ensure that the data and the MC are processed with the same matching criteria before offline analysis, or we bias tracking efficiency evaluations.

MC requests for Sim10e and Sim10f block7/8 data currently use releases which include these new matching criteria by default! This is a danger as it silently adds a data-mc deviation.
This MR fixes this by adding a keyword argument exposed to lbexec, --trkeff-probe-matching.

• the default, --trkeff-probe-matching=2024-like, is equivalent to the option used in 2024 data-taking, i.e. not using the new criterion
• the alternative, --trkeff-probe-matching=2025-like, can be explicitly opted-into by experts, is equivalent to the option used in 2025 data-taking, i.e. using the new criterion. Then it's up to the experts to remember that if they do this they need to re-process 2024 to update the matching criterion likewise.
• Any other choice is caught by argparse's choices error handling

ToDo

• ci-test
• Decide on default (2024-like or 2025-like)
• Included in a new v55r{11, 12, 13, 14, 16} release
• Usage in MC requests