Refactor LockSpecification as a Dictionary from Platforms to List of Deps

[srilman]

Description

As discussed in https://github.com/conda/conda-lock/pull/374, https://github.com/conda/conda-lock/issues/278, and previously implemented in https://github.com/conda/conda-lock/pull/316, this PR refactors the LockSpecification class to store all dependencies as a dictionary from platforms to a list of dependencies required for the platform.

After this PR, it is no longer necessary to have the Selector class, so it is also removed in this PR.

This PR still maintains source parsing code to return LockSpecification classes. This is not an ideal solution, since it requires parsing the source file multiple times. In the future, I will implement a PR to have a custom SourceFile class, like implemented in https://github.com/conda/conda-lock/pull/316.

[netlify[bot]]

✅ Deploy Preview for conda-lock ready!

Name	Link
🔨 Latest commit	3ce07dc4c8aae03faa724bdf79d3d53333cd591b
🔍 Latest deploy log	https://app.netlify.com/sites/conda-lock/deploys/64051de18a77c40008699c44
😎 Deploy Preview	https://deploy-preview-383--conda-lock.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[maresb]

This is magnificent!!! I love that we were able to delete so much code. It's nice to see the CI green. And now the code logic agrees with my mental model. All this makes very happy. :smile:

During my review I cleaned up some of the preexisting code a bit further: https://github.com/srilman/conda-lock/pull/1. If you agree, let's wrap that into this PR by merging on your fork.

I've reviewed this thoroughly, and from my side this is good to go.

Since this is such a substantial structural change, I think we should get approval from @mariusvniekerk.

[srilman]

@maresb I'm happy with the additional code cleanup in my local branch. I'm going to merge your branch into this one.

[maresb]

For orientation as to how this fits into the big picture:

What conda-lock does in a nutshell:

• Each source file (environment.yml, pyproject.toml, etc.) is preprocessed in order to compute the target platforms (linux-64, osx-64, etc.).
• With the target platforms in hand, each source file is processed in order to extract the dependencies required for each platform. The result is a list of LockSpecifications, one for each source file.
• The LockSpecifications from the individual source files are aggregated into a single LockSpecification.
• The aggregated LockSpecification is solved for each platform, resulting in a big list of LockedDependency objects.
• These LockedDependency objects are packed with various metadata into a Lockfile object.
• The Lockfile object is converted into the desired output format.

This PR reworks the internally-used LockSpecification data structure so that its implementation is more in line with how it's actually used.

[srilman]

To clarify further, this will not change how we parse input files or the resulting output lockfile in any way. This will only change an internal data structure so that it is easier to implement future changes. For example, I was working on a future PR to support encoding multiple categories in the lockfile, but kept running into bugs because of how we grouped all platforms together in the LockSpecification.