Update tests to work without ambertools/with openeye

[lilyminium]

This PR updates tests to ensure they can run without ambertools, or with openeye, installed. Passing tests in [this set of actions](https://github.com/openforcefield/smee/pull/140/commits/08108785ce7fa7d4e0b4b87fc77114ceff51d5f50.

This also updates the CI workflow. I've changed the following:

• creates an ambertools and openeye environment respectively
• modified the workflow to not use the lockfile for Ubuntu environments. This was not possible for Mac because Pixi tries to resolve the cuda environments and runs into cross-platform issues, even though none of the environments here use the cu12 feature [?]. Pixi did successfully resolve the ambertools environment, though, so maybe I'm still doing something wrong.
• The workflow was modified to not use the lockfile because for CI, it seems more desirable to test the most up-to-date versions of the ecosystem at any point, including very upstream dependencies that we don't specify in pyproject.toml.
• It would be very nice to be able to test different Python versions in the GitHub matrix in the same way we're accustomed to doing with Conda workflows, instead of needing to clutter up pyproject.toml with additionally specified Pixi environments. I haven't worked out how to do this yet.

[lilyminium]

This should wait until #131 since that makes substantial changes to the CI / env workflow

[Yoshanuikabundi]

This looks good! Locking the environment on MacOS but not Ubuntu is weird, and it would be nice to fix it if we can, but I don't think it's necessarily blocking anything. I've found two possible candidates for what could be causing it, so would be good to investigate those before merging. I also note that Ambertools seems to be required in all environments - is that intended?

RE: Cluttering up pyproject.toml - I've really enjoyed keeping pixi stuff in pixi.toml, since it gets to be such a big file even in small projects and the more focused file makes things a lot easier to navigate. The downside is that it doesn't encourage you to use the dependency-groups and project.dependencies fields in standard pyproject.toml files, but we're not using them here anyway so that's not a huge loss.

I think the really big win we get from using Pixi environments in CI is that there's a single source of truth for environments that can be used by devs on their own machines, users trying the examples, and CI. It means potential contributors don't have to go digging in the CI config to figure out how to get started when we forget to document it properly, or the documentation goes out of date. I think this is a huge win that more than makes up for having to enumerate every environment in the matrix.

It would be nice to be able to construct ad-hoc environments from a list of features though! That might be the best of both worlds.

[lilyminium]

Amazing -- thanks Josh, that update definitely did the trick! I really like the idea of a pixi.toml for separating things out from pyproject.toml -- will look into that.

[lilyminium]

I do seem to have uncovered a real bug in interchange which is out of scope of this PR...