Decrease probing budget after some limit

[Opt-Mucca]

This PR adds stricter limits on probing after 2500 columns have been probed on. Specifically, it decreases the amount of deleted columns used as a stopping criteria, and changes the weights used to calculate the dynamic probing budget.
This fixes worst-case performance for #2478 where HiGHS was probing on everything for a huge amount of cliques / some deletions, despite the instance being easy to solve regardless.
I've run some experiments on 60 or so instances, with most being unaffected, and some minor improvements that I'd say are noise. This change is only likely to affect large instances. The PR needs to go through more rigorous computational experiments before being merged.
I decided on the numbers from playing around a bit on some instances. They're unlikely to be perfect (as the original ones aren't), so am open to any changes / new approaches. I tried to be conservative because I don't want to ruin probings effectiveness on other instances just to avoid these fringe cases.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.73%. Comparing base (313b07a) to head (c47a396).
⚠️ Report is 144 commits behind head on latest.

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #2512      +/-   ##
==========================================
+ Coverage   79.48%   79.73%   +0.24%     
==========================================
  Files         346      346              
  Lines       85869    85986     +117     
==========================================
+ Hits        68251    68558     +307     
+ Misses      17618    17428     -190     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[galabovaa]

Great!

[galabovaa]

LGTM

[fwesselm]

Looks good, thanks @Opt-Mucca. I am going to test this now.

[fwesselm]

This is a question of taste, but if you would want to avoid the if-else, you could have the following here:

     bool tightenLimits = (numProbed - oldNumProbed) >= 2500;
     HighsInt multiplier = tightenLimits ? -1 : 1;
     // when a large percentage of columns have been deleted, stop this round
     // of probing
     // if (numDel > std::max(model->num_col_ * 0.2, 1000.)) break;
     probingEarlyAbort =
         numDel >
         multiplier *
             std::max(multiplier * HighsInt{1000},
                      multiplier * (model->num_row_ + model->num_col_) / 20);
     if (probingEarlyAbort) break;

[Opt-Mucca]

Sorry for missing this comment! I'm happy with if-else logic. I find it easier to read than the double multiplier.