Reintroduce python_min for testing

[h-vetinari]

Follow-up to #331, where we removed the pin to unblock downstreams: testing on the feedstock for conda. Ideally we should be testing with the lowest python version here (an potentially also the highest), without creating an unsatisfiable constrain in the dependency metadata for the test portion. Some relevant comments

@jaimergp: A (bad) alternative is to make this package non-noarch and build/test as a matrix. The downstream design is not perfect so we are going to run into limitations with the amount of workarounds required to test something.

@h-vetinari: Yeah, I get that this is a bit of an annoying limitation of CFEP-25. We want to use the oldest python version for testing (reasonable!), but with the current setup this creates a permanent pin from the POV of the conda metadata for the testing portion of the package. Ideally we could run with the oldest python here without creating that metadata constraint...

@wolfv: python min should not affect downstream tests in the slightest in v1 recipes.

@h-vetinari: How does that work? My understanding is that if anything, smithy would need to move to v1, not conda, because it's smithy that currently hard-codes the test-requirement of python 3.9. Or what am I missing? Even rattler-build shouldn't be able to just arbitrarily ignore test requirements for downstreams: tests...?

@wolf: you can have multiple independent tests in v1 recipes

@h-vetinari: I can understand that part conceptually. This should also make it possible to run against both newest and oldest python versions here, right?

Originally posted by @h-vetinari in #331 (comment)