feat(proposal): use where selector to manage class specificity

[Allyhere]

Bug description

I noticed that buttons with utility color classes turn blue on :hover.

If the example below is the expected behavior of these buttons, I believe this is a specificity bug:

Using the .default variant as an example, this is the CSS with the intended behavior:

button.default:not(:disabled):active,button.default:not(:disabled):hover {
    background: var(--default);
    color: var(--contrast)
}

It produces a 0,3,1 specificity and it is being overridden by this selector, which also has a specificity of 0.3.1 because its declared further on the code.

:is(button,input:is([type=submit],[type=reset],[type=button],[type=image])):not(:disabled):active,:is(button,input:is([type=submit],[type=reset],[type=button],[type=image])):not(:disabled):hover {
    border-color: transparent;
    background: var(--accent);
    color: var(--light)
}

Proposal - Using an :where selector as an architectural axiom

Note

This solution is agnostic and non-obstrusive and have sufficient browser support but it will require a more comprehensive change and may potentially lead to a major version increment.

Every CSS subdirectory acts as a module that serves both base styles and utility-oriented styles. For base styles related directly to HTML elements, you may want to maintain the lowest specificity possible to avoid collision with utility styles.
I suggest Elad Shechter approach on CSS Reset. This ensures that every "base" styles will be safely overridden.

Pros
For better composability and overriding of classes, I tried to maintain specificity levels at 0,0,1 for base styles and 0,1,x for states and pseudo to reduce the chances of overriding base styles by resets or subsequent modules.

Cons
This solution results in more complex selectors, and consequently slower, which within the scope of this library would not affect most users. However, it would complicate debugging and maintenance.

Closes #42