#6922)

* improve extractCandidates

When we have a css rule that is defined as `.foo, .bar {}`, then we will
crawl each selector and link it to the same node. This is useful because
now our Map looks something like this:

```js
Map(2) { 'foo' => Node {}, 'bar' => Node {} }
```

This allows us to later on `@apply foo` or `@apply bar` and we can do a
direct lookup for this "candidate".

When we have css defined as `span {}`, then we consider this
"non-ondemandable". This means that we will _always_ inject these rules
into the `*` section and call it a day.

However, it could happen that you have something like this: `span, .foo
{}` up until now this was totally fine. It contains a non-ondemandable
selector (`span`) and therefore we injected this into that `*` section.

However, the issue occurs if you now try to `@apply foo`. Since we had
an early return for this use case it didn't endup in our Map from above
and now you get an error like:

```
The `foo` class does not exist. If `foo` is a custom class, make sure it
is defined within a `@layer` directive."
```

So instead what we will do is keep track whether or not a css rule
contains any on-demandable classes. If this is the case then we still
generate it always by putting it in that `*` section. However, we will
still register all on-demandable classes in our Map (in this case `.foo`).

This allows us to `@apply foo` again!

* update changelog

* partition nodes as soon as possible

Time to write another story on `@apply`...

When we write code like this:

```css
.a {
  @apply b;
}

.b {
  @apply uppercase;
  color: red;
}
```

Then we create 2 Nodes in our context to keep track of. One has
identifier `a`, the other has identifier `b`. However, when we have an
`@apply` and it contains multiple declarations/atrules, then we have to
split up the (aka partition) node into multiple nodes so that we can
guarantee the correct expected sort order.

This means that the above example technically looks like this:

```css
.a {
  @apply b;
}

.b {
  @apply uppercase;
}

.b {
  color: red;
}
```

If this was your input, then we would still have 1 node for identifier
'a', but we would have 2 nodes for identifier 'b'.

As mentioned earlier, this is important to guarantee the correct order,
here is an example:

```css
.b {
  @apply md:font-bold xl:font-normal; /* Here we can sort by our
  internal rules. This means that the `md` comes before `xl`. */
}
```

... however

```css
.b {
  @apply xl:font-normal; /* This now exists _before_ the example below */
}

.b {
  @apply md:font-bold; /* Because we respect the order of the user's css */
}
```

So to guarantee the order when doing this:
```css
.b {
  @apply xl:font-normal;
  @apply lg:font-normal;
}
```

We also split this up into 2 nodes like this:
```css
.b {
  @apply xl:font-normal;
}
.b {
  @apply lg:font-normal;
}
```

The tricky part is that now only 1 empty `.b` node exists in our context
because we partitioned the orginal node into multiple nodes and moved
the children to the new nodes and because they are new nodes it means
that they have a different identity.

This partitioning used to happen in the expandApplyAtRules code, but
this is a bit too late because the context has already been filled at
this time. Instead, we move the code more to the front, as if you wrote
those separated blocks yourself. Now the code to inject those nodes into
the context happens in a single spot instead of multiple places.

Another good part about this is that we have better consistency between
each layer because it turns out that these two examples generated
different results...

```css
.a {
  @apply b;
}
.b {
  @apply uppercase;
  color: red;
}
```

... is different compared to:

```css
@tailwind components;
@layer components {
  .a {
    @apply b;
  }
  .b {
    @apply uppercase;
    color: red;
  }
}
```

Even if both `a` and `b` are being used in one of your content paths...
Yeah.. *sigh*

* add more `@apply` related tests

* update changelog

* remove support for basic nesting (leftover)

* remove leftover todo

This has been fixed already

Co-authored-by: Adam Wathan <[email protected]>