feat: release language server as npm package

[adalinesimonian]

Resolves #110

Move the language server, DI framework, and shared utilities into a separately publishable @stylelint/language-server npm package under packages/language-server/. The extension now imports from @stylelint/language-server via an npm workspace dependency instead of relative paths. A standalone bin entry point is included so the server can be started via npx @stylelint/language-server --stdio or integrated into other editors.

This resolves the last remaining feature request we've had open for years. No longer must maintainers of downstream integrations with other editors, have to futz around with hacky workflows built around patching their work into this repository. Now, we have a clean split at the language server boundary. This will make it easier both for other maintainers, but also for us in supporting them in case anything ever comes up.

The build uses TypeScript project references. Wireit tasks and scripts have all been updated for the new paths, and contributors should see very little change in their day-to-day work beyond the moving of the language server/DI code. Changesets handles multi-package versioning, and the updated release workflow publishes each package independently when its version changes. The developer- and maintainer-facing documentation has been updated to reflect the slight adjustments to workflow and to explain when to designate updates for each package.

The shared release workflow is not meant for monorepos, and so here I've kept the workflow - in the general, non-GitHub Actions meaning of the term - the same, but written our own logic here. In the future, if it makes sense, we can explore updating shared workflows for monorepo support, but I don't want to remain blocked on that for this. This also gives us a good testing ground to test and validate these changes without involving other repos.

No settings, commands, or runtime behaviour changed. The vast majority of the changed files are just file moves; there are overall not that many actual changes in this PR.

Some notes:

• The first publish of @stylelint/language-server will in all likelihood fail, as I don't believe the OIDC-based trusted publisher flow can be used for the first publish of an npm package. There seems to be no way in npm to configure trusted publishing pre-emptively for a package that doesn't exist yet, i.e. claim the package name and tie it to a trusted publisher. We'll have to let the release workflow do its thing, then publish manually for the first version.
• packages/vscode-stylelint is a virtual package that gives Changesets something to grab onto. In a monorepo, Changesets does not consider the root package a deliverable that needs versioning and ignores it. However, the VS Code tooling plays nicer when the extension itself is not in the monorepo. The versioning script syncs the version given to the virtual package with the root package, and code for the extension stays in src/extension.
• Since this is the first version of @stylelint/language-server, I have deliberately not annotated any of the existing changesets as affecting the language server package. Normally, we will mark changesets as affecting the language server whenever the change affects any of its consumers (see the updated CONTRIBUTING.md). But in this case, since this is the first release, it does not make sense for the changelog to have anything other than the line saying that it is the first release - there is no previous version to compare v1.0.0 to.

[jeddy3]

Amazing to see this, especially with more editors on the scene than ever before.

We'll have to let the release workflow do its thing, then publish manually for the first version.

Yes, I believe that's the case.

With the switch to changesets, there will be a few different moving parts during the next release process. We'll likely run into a couple of snags, but we can iron them out as we encounter them.