New feature resolver, workspace inheritance

This MR adds support for weak dependency features, and the new optional feature syntax, as well as workspace inheritance of cargo toml properties.

Feature resolver

I've completely rewritten the resolver.rs file, in order to support the new features. I stopped using overlays and instead went with attribute sets together with a merging function. I thought I could do it entirely stateless (without remembering which features were activated before the one we're activating), but I think it is impossible, exactly because of weak dependency features. Instead, the code looks more like a continuation passing style, where I pass the state of the packages into the next function (the seen argument, present in almost all functions).

Still, the code does look very similar to cargo's new feature resolver code, and it gives pretty good results: I've been able to compile cargo and alacritty with it and it is reasonably fast. Both of them are quite feature/dependency heavy so I think they give a fairly good stress test.

There still are some rough edges that I'm not sure I implemented correctly, mainly dev features not ending up mangling with normal features (see resolver.nix#L195), but the way I fixed it seems to give correct results. Also, nix flake check is failing, but with an error related to gen-workspaces git sources (it seems like there are some old urls? I haven't given a proper look), and I don't believe my changes have caused it.

Workspace Inheritance

This feature was mainly needed in order to compile cargo, because it is used fairly often there. The main changes that come from this is that pkgSet now must hold the edition when we call mkPkgInfoFromCargoToml, which also needs workspace variable to inherit from. I haven't added all the features that should be added here, just the ones necessary to compile cargo.

I believe I've fixed the nix flake check issue. When rigille added the nix-filter, he forgot to add it for the tests too.

Thanks for your review! I will address some comments, but I think it is worth going back and rewrite it in a overlay based approach. The main ideas should stay the same, and I think it should overall be faster. I'm also interested in seeing how NixOS's merging functions work, because they do almost the same things as I was trying to achieve (concatenate lists and or booleans on merge), and they seem to work relatively well for that.

The main problem that I had when I tried using overlays was deep changing the features sets without overriding any other part (which is what made me write the mergeChanges function), because they looked so unnatural and so ugly that I had to think that I was doing something wrong.

But yeah, just to finish up. The seen argument present in all the functions is already the prev: argument provided in the overlay approach, I would just need to add the final and switch a little bit the functions in order to use overlay functions. I think that the main issue would be that I would still like to go with the approach that I did (of merging the attribute sets), and overlays are kind of orthogonal to that.

I think it is worth going back and rewrite it in a overlay based approach.

I was also working on this and had some sketch code. It would be good to estimate its complexity and performance comparing to the current PR before the decision on algorithms. So no need to rush rewriting it :)

Could you please make another PR for the workspace inheritance (with edition passing)? We can finish that first.

I can, I will get it done next week. The actual code pertaining to that is much much smaller and relatively simple, compared to the resolver.

Any update on when this will be updated and merged in? I'm currently using this fork to use nocargo since I have v2 dependencies.

@therishidesai I would recommend using this one https://gitlab.com/deltaex/nocargo until this branch merges, we've been using that in production for the last months so it tends to receive updates/fixes faster