[WheelVariants] Implement getting sorted variants aided by variants.json

[mgorny]

Add a variants_json argument to get_variant_hashes_by_priority() that enables the function to use variant definitions from variants.json instead of evaluating all possible combinations. This can yield significant speedup and lower resource use if only a handful of variants need to be considered.

The function is implemented without any plugin API changes. After all, the current API should be simpler for plugin authors, and generating separate variant lists should not pose a performance problem.

Implemention-wise, the function first converts all variant descriptions from variants.json into VariantDescription classes. Then, the list of variants is fitlered to include only variants that match configurations obtained from plugins. Finally, they are sorted using the configuration order.

I am not 100% sure about the sorting algorithm, but it seems to yield exactly the same order at least for the dummy-project wheels. The first element of the sort key is the number of metas in the variant, to prioritize variants that matched more items. It is followed by priorities (indices in configuration order) of all metas, ordered from the most preferred to the least preferred.

[mgorny]

I've also added warnings for missing providers/keys now, e.g.:

VariantLib: No plugins provide the following variant providers: fictional_tech; some variants will be ignored
VariantLib: The provider fictional_hw does not provide the following expected keys: architecturex; some variants will be ignored

This could suggest that either some package is missing, or perhaps it's outdated/in the wrong version.

[mgorny]

I'm going to add a test that verifies that the variants.json-based sorting produces the same order.

[mgorny]

Hmm, so apparently we're seeing a mismatch in two-value variants. If I'm reading the diff correctly, the original algorithm prfers all custom_hw :: driver_version + custom_hw :: hw_architecture variants over custom_hw :: driver_version + networking :: speed, but the new algorithm intersperses them. Need to fix that.

[mgorny]

@DEKHTIARJonathan, do we care about Python 3.10 compatibility in the prototypes, or should I skip testing on 3.10 for now?

[mgorny]

Okay, this should finally be correct. I've added a fuzzing test too, to get better coverage.