Use stable order for dependencies

[konstin]

Fixes #373.

By using a Vec instead of an [Fx]HashMap for DependencyConstraints, the insertion order of dependencies becomes deterministic, and thereby our internal prioritization. This fixes the problem in #373 where priorities, and thereby resolutions, can change depending on the platform, such as 64-bit vs 32-bit. Now, the first package in a dependency list is always prioritized.

As DependencyConstraints had exposed the FxHashMap, this is breaking change that requires pubgrub v0.4.

I made SelectedDependencies opaque too for good measure.

[codspeed-hq]

CodSpeed Performance Report

Merging #377 will degrade performances by 25.64%

_{Comparing konsti/dev/use-stable-iteration-order-deps (a1698ae) with dev (c8a9d87)}

Summary

❌ 3 regressions
✅ 3 untouched

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
❌	Simulation	backtracking_singletons	4.3 s	4.5 s	-5.03%
❌	Simulation	sudoku-easy	3.7 ms	5 ms	-25.64%
❌	Simulation	sudoku-hard	4.4 ms	5.3 ms	-17.95%

[mpizenberg]

I’d really love to have @Eh2406 point of view on this, especially performance-wise. Because all data structure changes in the lib have potential to significantly degrades performances.

[Eh2406]

Overall having control over our types is a huge improvement.

For DependencyConstraints Forcing an allocation at all seems a little wasteful. I wish we could take -> impl Iter. The type shenanigans required to pull that off are quite extraordinary, and probably not worth it. But if we have to do an allocation, Vec is not worse that Map. (Although somewhat academically I do wonder why the benchmarks disagree with me.)

[konstin]

I haven't checked, but I assume the sudoku perf regression is due to the changed traversal order, we call get dependencies a max of 999 and realistically much less, I don't see how this could have that much of an impact.