Improve candidate extraction when candidates contain . characters

[RobinMalfait]

This PR fixes an issue where some classes weren't properly extracted due to some incorrect assumptions in the pre processors.

Templating languages such as Haml, Slim and Pug allow you to write classes in a shorter way that are not properly contained inside of strings. E.g.:

p.flex.px-2

These candidates are not properly extracted because there are no bounding characters like quotes. To solve this, we pre-process it and replace . with characters. This results in something like:

p flex px-2

However, this has some challenges on its own. Candidates like px-2.5 cannot be written in this shorthand form, instead they need to be in strings. Now we cannot replace the . because otherwise we would change px-2.5 to px-2 5 which is wrong.

The next problem is that we need to know when they are in a "string". This has another set of problems because these templating languages allow you to write normal text that will eventually be the contents of the HTML tags.

.text-red-500.text-3xl
  | This text can't should be red
                 ^ Wait, is this the start of a string now???

In this example, if we consider the ' the start of a string, when it's clearly not, how would we know it's for sure not a string?

This ended up as a bit of a rabbit hole, but we came up with another approach entirely if we think about the original problem we want to solve which is when do we change . to characters.

One of the rules in our current extractor is that a . has to be between 2 numbers. Which works great in a scenario like: px-2.5. However, if you look at Haml or Slim syntax, this is also allowed:

p.bg-red-500.2xl:flex
           ^^^ Uh oh...

In this scenario, a . is surrounded by numbers so we shouldn't replace it with a space. But as you can see, we clearly do... so we need another heuristic in this case.

Luckily, one of the rules in Tailwind CSS is that a utility cannot start with a number, but a variant can. This means that if we see a scenario like <digit>.<digit> then we can just check if the value after the . is a valid variant or not.

In this case it is a valid variant so we do want to replace the . with a even though we do have the <digit>.<digit> format.

🥴

Test plan

1. Added additional tests.
2. Existing tests still pass

[philipp-spiess]

Unfortunately this still breaks if a double-quote is used in the text. :/

@RobinMalfait have been chatting about this and we'll going to revert the string-based handling of dots inside utilities in pug and instead make it replace dots to space unless:

• They are surrounded by numbers. That's what we do in Oxide right now: https://github.com/tailwindlabs/tailwindcss/blob/main/crates/oxide/src/extractor/named_utility_machine.rs#L247-L261
• They are inside a bracket stack (so arbitrary stuff works)

This way we can avoid thinking about strings in this languages

[RobinMalfait]

A bit silly, but the . and # characters are replaced because:

1. The . is not surrounded by numbers
2. The # is replaced because it's not inside of a bracket stack

While this does break the string, it doesn't matter from Tailwind's perspective and since we're not updating the real code, it's not an issue.

This was from before the new implementation. Removing so we can enable auto-merge.

[philipp-spiess]

I like this approach a lot more. Having to worry about what these template languages consider strings and not felt like a rabbit-hole where the solution is to have a full parser for those languages. This fix is more surgical for sure 👍