- Change `Config` interface to refer to `rootUri` instead of `root` as an absolutePath
- Get rid of `fileExists` DI in theme-check Dependencies
- Get rid of `fileExists` DI in theme-language-server Dependencies
- Add `fs` DI in theme-check Dependencies
- Add `fs` DI in theme-language-server Dependencies
- Add `MockFileSystem` implementation (for tests)
- Add `NodeFileSystem` implementation
- Add optional `fs` argument to `theme-language-server-node#startServer()`

The `fs` DI has the following interface (so far):

```ts
interface FileSystem {
  stat(uri: string): Promise<{ fileType, size }>;
  readFile(uri: string): Promise<string>;
  readDirectory(uri: string): Promise<[uri: string, fileType: FileType][]>;
}
```

theme-language-server-node now also accepts an optional `fs` implementation in startServer.

Instead of having that logic be injected in, I added an abstract
implementation in theme-check-common that depends on the virtual file
system. We will no longer need to inject this behaviour :)

FileSystem is an ambient import which made the DX suffer when
refactoring code. It's also more obvious now that the FileSystem
interface is an interface that you need to implement, not something
concrete that you can use directly.

Replace it with URIs. That way we won't need to worry about windows paths being weird.

The only place where we still have them is for places where we deal with `glob` and `loadConfig` in `theme-{check,language-server}-node`.

- SourceCode.absolutePath -> SourceCode.uri
- etc.

We still have an optiomal dependency that is otherwise implemented by a
naive implementation (for CLI use cases), but in the language server we
prefer the buffer over the file in the file system...

Which makes me think we could get rid of that by actually making that
logic part of the getTranslationsFactory directly. Prefer theme files
over fs.

All that logic didn't need to be in the language server.

This makes the dep injection easier too because we no longer have this
upstream concern.

Replace with AbstractFileSystem-based implementation

Replace with abstract-file-system-based implementation

TODO make that shit faster. Seems highlighy unoptimized.

Replace with abstract-file-system-based implementation in common code.

- Adds support for VS Code for Web
- Adds support for remote files

You don't need to query VS Code _every time_ the user types something
for the same imformation. That's rather slow!

We'll invalidate the relevant caches when files are
saved/deleted/created/renamed.

Made to demo what it's like to use a VirtualFileSystem in a
non-vscode environment.