[ATLIDTRKCP-309] Revert usage of pattern-holes in ambiguity resolution

This MR picks up on the discussion following !38307 (closed) and the Nov 17th Reconstruction meeting.

After the meeting, we had a follow-up chat with @elsing. In the course of this, we realised there are further logical inconsistencies in the ambi solver when using pattern-holes, which may have a detrimental impact on b-tagging performance that our current validation might not be able to quantify correctly.

Since we are so far beyond the feature freeze, we agreed that the best way forward at this point is to be conservative and, instead of deploying "Option 2" discussed at the meeting, to go back to the original approach we had before introducing the pattern hole strategy. This will cost us 10% tracking CPU, but restore the excellent purity and optimal b-tagging performance known to be provided by the use of precision holes within the ambi.

This change can be achieved by toggling a single flag, so this is a very simple MR. We hope that this does not change the outcome of today's discussion regarding the sample production.

Adding @npetters @sroe @vcairo @mdanning @biliu @elsing @amorley from the tracking side, @goetz @mhodgkin @emoyse @elmsheus for reco/SW, @willocq @gunal for PC and @demers @smwang for DP.