Option use_implied_bounds_from_presolve is now redundant

[jajhall]

Description

Fuzzing by @odow (issue-010) identified an error in a dual value when the use_implied_bounds_from_presolve option was used.

Essentially, it tightened the upper bound on a variable "y" from 3 down to the variable's optimal value of 11/6. IPX without crossover gave "y" a small dual value (-0.0007) that was feasible with respect to the upper bound of 11/6, but not feasible with respect to the original upper bound of 3. This dual value cannot be corrected, since it's uniquely defined by the row duals - which were feasible but (naturally) slightly different from the dual values after crossover (when the dual on "y" was zero).

This resonated with the study of fuzzing issue-009, when presolve was stopped by setting presolve_reduction_limit and yielded an LP min -1 + x, s.t. 7 <= x; x >= 7. This clearly has a single feasible primal value, but feasible dual values are non-unique. IPX without crossover gave dual values led to infeasibility in postsolve, and can't be fixed since they require the row dual to be modified. For this instance, without presolve_reduction_limit, identifying the singleton row would fix x=7 and reduce the LP to empty. primal-dual postsolve was then correct.

The moral of both is not to introduce dual non-uniqueness unnecessarily.

Hence this PR removes the ability to use the implied bounds after presolve. The option was off by default - since it didn't appear advantageous - and now its description notes that it is redundant.

Checklist

• I have read the contributing guidelines
• This PR targets the latest branch
• Tests are passing
• Documentation was updated where relevant
• This PR is not primarily AI-generated (per the AI contributions policy in CONTRIBUTING.md)