Add Solver.resolve() and Model.apply_result() for iterative re-solve workflows

[FabianHofmann]

closes #198

Changes proposed in this Pull Request

This PR adds support for iterative re-solve workflows where users solve a model once, modify the native solver object directly (e.g. change objective coefficients or bounds), and re-solve without rebuilding the linopy model.

New APIs:

• Solver.resolve(solver_model, sense) — re-solves an existing native solver model and returns a Result. Implemented for HiGHS, Gurobi, and Mosek; raises NotImplementedError for other solvers.
• Model.apply_result(result, solver_name) — resets the current solution and maps a solver Result back onto the model's variables (primal) and constraints (dual).

Refactoring:

• The solution-mapping logic previously inlined in Model.solve() has been extracted into apply_result(), which solve() now calls internally. No behavioral change for existing users.

Documentation:

• New notebook examples/iterative-resolving.ipynb demonstrating the full workflow: initial solve, native model modification, re-solve loop, parameter sweep, and infeasible result handling.
• Notebook linked into the Sphinx docs under the User Guide section.

Tests:

• test/test_resolve.py covering apply_result (optimal, infeasible, None solution), Highs.resolve() end-to-end, and NotImplementedError for unsupported solvers.

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
• Unit tests for new features were added (if applicable).
• A note for the release notes doc/release_notes.rst of the upcoming release is included.
• I consent to the release of this PR's code under the MIT license.

[FBumann]

Cool addition. Also nice internal refactor.
How urgent is the review? Hours, days, weeks?

[FabianHofmann]

not urgent at all, it is also not a big change and only slight refactor, so should not take long to review