Compute correct document selectors when a project is initialized

[thecrypticace]

Fixes #1302

Possibly helps #1322
Possibly helps #1323

This PR fixes a problem where files may fail to match against the appropriate project in a given workspace — and in some cases this behavior could be "fixed" by opening multiple files until all projects in a workspace had their selectors recomputed. (A selector is a file pattern/path paired with a "priority" that tells us how files match different projects in a workspace)

The problem here is caused by a few things:

• We fixed a bug where auto source detection in v4 silently failed in IntelliSense. After fixing this a file could get matched against one of the globs or file paths detected by Oxide.
• A workspace with lots of CSS files may end up creating more than one "project"
• Upon project initialization we would recompute these selectors based on the resolved JS config (necessary for v3 projects because we compile ESM or TS configs during intiialization and not discovery).

Obviously, v4 projects do not have JS configs (even if you're using @config or @plugin it's not actually the config file we care about. It's the design system created from the CSS file that matters.) so we were then throwing away these document selectors.

In a workspace with multiple detected projects (could be because of multiple CSS "roots", some v3 and some v4 files, etc…) we would check the file against the selectors of each project, pick out the most specific match, then initialize the project. The problem is that, when we re-computed these selectors during initialization they changed. This has the side effect of dropping the patterns that we picked up from Oxide for a v4 project.

This would then cause any subsequent requests for a file to match a different project. So for example, a request to compute the document colors would cause a project to be matched then initialized. Then a hover in the same file would end up matching a completely different project.

This PR addresses this by doing two things:

1. Using the same codepath for computing a projects document selectors during discovery and initalization
2. Normalize Windows drive letters in source paths picked up by Oxide. This would have the effect of some content paths not matching a project when it otherwise should on Windows.

In the future it'd probably be a good idea to make documents "sticky" while they are open such that an open document picks a project and "sticks" to it. We'd still want to recompute this stickiness if the config a file is attached to changed but this is a future task as there might be side effects from doing this.

[philipp-spiess]

Not really sure what the change in behavior here is besides the drive letter normalization. Do you mind clarifying this?

[thecrypticace]

Ah yeah I'll tweak the description a bit later with information on before/after but the gist is:

• On v4, auto content detection stuff got cleared when a project was initialized
• On Windows, generally, sometimes content paths had a different drive letter casing so a document might not get picked up as matching a content path and would skip to the next project incorrectly. Mostly affects v3 and earlier.

Both of these only affect workspaces with multiple projects but in v4, because CSS files, IntelliSense is more likely to pick up multiple projects even if there really should only be one.