Move away from dependence on gurobi.sh

[jsiirola]

Fixes #3285 .

Summary/Motivation:

Gurobi has deprecated the use of the gurobi.sh script, which is used by the default Pyomo interface to Gurobi. While we could have just changed the default interface to gurobi_direct, this PR does not go down that path because:

• gurobi_direct is significantly less performant than the current LP shell interface
• the gurobi_direct has a slightly different API
• we want to retire / replace all the solver interfaces in pyomo.solvers "soon"

Instead, this PR adds a new solver that is a relatively thin veneer around the GUROBISHELL interface that avoids the subprocess call and the need to write results to a "soln" file. While this is adding yet another interface, it offers a minimally-disruptive path to avoid the deprecation warnings that will appear in Gurobi 12.

Changes proposed in this PR:

• Refactor GUROBI_RUN so that the bulk of the functionality can be executed directly (pulling out the soln file writer to a separate function)
• Add GUROBIFILE as a LP/MPS file-based input, direct interface output solver interface that has maximal overlap with the current GUROBISHELL.
• Remove GHA pin of Gurobi to 10.0.3
• Update tests to "not fail" in Gurobi 11

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[mrmundt]

This comment also appears to be wrong.

[jsiirola]

No - this is still correct. I updated the comment to clarify it a bit.

[jsiirola]

The test failures in Jenkins are real; however, I need #3394 to resolve the issue.

[blnicho]

I have a couple questions but nothing major enough to prevent merging

[blnicho]

Now that #3394 has been merged can the changes in this file be reverted?

[blnicho]

Oops, I just noticed the last commit message which seems to already be using the deferred config stuff so ignore my original question. Is the Solver domain implemented here general enough to go into pyomo.common or pyomo.util?

[jsiirola]

It is pretty general, but could use some discussion before promulgating it elsewhere. In particular, what is the "correct" way to know if you were handed a "solver" object? Given that we have 3 different base classes floating around (core, APPSI, and contrib/solver), inheritance is probably not the right answer. This implementation just looks for a solve() method and hopes it quacks.