[FEATURE] Add a utility class to calculate selector specificity

[oliverklee]

Calculating and caching the specificity of a selector is a different concern than representing a selector, and it deserves to be in its own class.

This also helps solve the problem of selectors having keep their specificity cached and in sync with the selector itself.

(We'll have a later change that changes Selector to use the new class.)

[coveralls]

coverage: 56.075% (+0.3%) from 55.799%
when pulling d0942df on feature/dependency-calculator
into f912e71 on main.

[JakeQZ]

Neat solution.

However, I'm not sure about the class name, as "dependency" has no known meaning in this context that I'm aware of. I think SelectorSpecificityCalculator would be more accurate. It could be in a child namespace so it becomes Selector\SpecificityCalculator. Either way, if the class name says what it is, the method and property names can then be simply calculate() (or perhaps getForSelector()) and $cache, as that it's for specificities would be implied by the class name.

My only other (minor) concern would be that by being static, it would build up a (small) memory footprint that would remain even after all use of the library was done with. There ought to be a way of having the dependent cache instantiated on creation of the first Selector, and destroyed upon destruction of the last Selector, but I can't think of anything (other than for the Selectors to maintain a count of how many of them there are, which seems ridiculous). So there might be a requirement for a public method to clear the cache.

[oliverklee]

However, I'm not sure about the class name, as "dependency" has no known meaning in this context that I'm aware of.

Me neither … I think I must have been really tired last night when I created that class. 😴

[oliverklee]

Updated and repushed.