[TASK] Always calculate selector specificity on demand

[oliverklee]

This avoids additional state that makes it hard to compare
selectors for equality.

Also, this will improve performance for cases where the
specificity is not needed (but will slightly worsen
performance where the specificity is queried multiple times
on the same selector instance).

Closes #1021

[coveralls]

coverage: 55.829% (-0.2%) from 56.006%
when pulling 8570e6b on task/specificity-on-demand
into 54ca442 on main.

[JakeQZ]

I think we should keep the optimization, as it would give a significant performance improvement, when, for example, sorting selectors by specificity, which would be quite a common use case. As long as the cached value if cleared when setSelector is called (which it is), I don't see it causing a problem.

We should, however, still remove the setting of the cached value in the constructor, as this is unnecessary (and a performance hit).

[oliverklee]

Calculating the value lazily and storing the cached value in Selector makes testing with this class quite hard (as can be seen in #1021).

To help solve this problem and still keep performance high, I've now created a caching utility class for this in #1049.

[oliverklee]

I have now changed `Selector' to use the new utility class.

[JakeQZ]

Neat.

[JakeQZ]

I removed the bit in the commit message about performance downgrade, since this is no longer the case.

[oliverklee]

I removed the bit in the commit message about performance downgrade, since this is no longer the case.

Thanks!