Get conda builds in GIthub workflow mostly working

[roryyorke]

meta.yaml and conda_build_config.yaml copied and adapted from conda-forge/slycot-feedstock.

The failures in testing on OSX seem to be due to something with coveralls; the failures happen (at least on my repo - tests yet to run here) at coverage-collection time, and this happens for both conda and wheel tests. I didn't change the wheel build, and these OSX wheel tests passed completely in the most recent merged PR gh-294.

I tried to get rid of the various conda warnings encountered through the build, but ended up with a free-threaded python (!) when testing against 3.13; when I tried to change meta.yaml to prevent that, the build broke in a mysterious way.

[roryyorke]

closed and re-opened to get Github actions to rerun, in the hope that whatever was broken with coverage on macos is now fixed.

[roryyorke]

The CI failures are in both Windows test runs, in tests unrelated to Slycot (I think). Evidently these two optimization cases are expected to not converge, but in CI they do.

@murrayrm I'm not familiar with the optimization code, and in particular if this problem should never converge (in which case I guess there's a bug somewhere), or if it's that whatever optimizer is used can now handle this problem (but why should Windows optimization only have this property?).

I see python-control has @slycotonly markers - I'm going to see if pytest can be told to run only those; it seems like it would be a reasonable thing to do anyway in Slycot, to reduce CI time and decouple from non-Slycot python-control code.

 FAILED control/tests/optimal_test.py::test_optimal_doc[shooting-3-None-xfail] - assert not True
+ where True = message: Optimization terminated successfully\n success: True\n status: 0\n fun: 98.05537313350811\n...74e+01 1.000e+02]\n [-2.000e+00 3.419e+00 1.991e+00]\n [ 0.000e+00 1.277e-01 -2.813e-01]].success
FAILED control/tests/optimal_test.py::test_optimal_doc[shooting-3-zero-xfail] - assert not True
+ where True = message: Optimization terminated successfully\n success: True\n status: 0\n fun: 98.05537313350811\n...74e+01 1.000e+02]\n [-2.000e+00 3.419e+00 1.991e+00]\n [ 0.000e+00 1.277e-01 -2.813e-01]].success
= 2 failed, 4255 passed, 39 skipped, 7 deselected, 10 xfailed, 1 xpassed, 299 warnings in 431.86s (0:07:11) =

[roryyorke]

I've opened python-control/python-control#1182 to allow only Slycot-dependent tests to be selected in pytest.

[roryyorke]

Tests pass, at last. I haven't checked the coverage decrease, but it may be because of decrease in coverage of python-control, not Slycot, since this only runs Slycot-related python-control tests. The reported decrease is relatively modest because I think coverage only reports coverage of Python files that are actually run. I imagine the true coverage decrease in python-control is higher. That's fine: we want to test Slycot-related things, not the whole of python-control.

I see auto-update-conda was previously explicitly set to false, I've set it to true; I did this because of the CI failures in 2c89932, which I'm pretty sure have nothing to do with Slycot. I don't know why it was previously set to false.

[roryyorke]

Coverage is only for the Slycot Python files, and the reduction in coverage was because my attempt to test "only" Slycot python-control functions wasn't quite right. See python-control/python-control#1185 for an updated version.

[roryyorke]

Coverage restored. Any objections to merging this?