Don't generate CSS for less specific utilities when a more specific utility matches

[adamwathan]

Resolves #14440.

This PR fixes an issue where registering a custom inset-shadow-* utility value in your theme like this:

@theme {
  --inset-shadow-potato: inset 0px 2px 6px #7a4724;
}

…mistakenly generates both an inset-shadow-* and inset-* utility with that value:

.inset-shadow-potato {
  inset: inset 0px 2px 6px #7a4724;
}

.inset-shadow-potato {
  box-shadow: inset 0px 2px 6px #7a4724;
}

We do this by making sure that when parsing a candidate name like inset-shadow-potato, we stop trying to find less specific matches as soon as we find any match. So once inset-shadow matches as a root with potato as a value, we don't try to match inset as a root with shadow-potato as a value.

This reverts some of the things we changed in #14231 that we can't for the life of us remember why we changed 🧠

Remembered why we didn't want to do this — if we only accept the most specific match it's possible for someone to completely override a core utility without really doing it on purpose.

For example, say for some cursed reason someone wants to change the color of all bold text by doing this:

@utility font-bold {
  color: red;
}

That will actually remove the font-weight: bold declaration from that utility in this case, because we don't explicitly register font-bold. We register font and handle bold as a value, so the user-defined font-bold will match as more specific, and our handler for font-* with bold as a value will never run.

No one should ever do this, but it does expose this other weird thing where we could refactor internals to use a static utility for a previously functional utility (or vice versa) and change the behavior of user-land code which just doesn't feel right.

Replacing this PR with #14447.

[adamwathan]

Get the fuck outta here PR.