Unless esbonio finds a `sphinx-build` command to use from the
user's config it will attempt to guess something reasonable. During
this process it generates a default build directory to use, in a
subfolder of `platformdirs.user_cache_dir()` so that it does not
interfere with the user's files.

Up until now, the moment a user sets their own `sphinx-build` command
this behavior is lost, which can lead to issues on some systems
(see #865).

This commit introduces a `${defaultBuildDir}` placeholder value that
the user can use to provide their own build flags, while maintaining
the default choice of build dir provided by esbonio.

Backslashes in Windows filepaths can cause issues

```python
>>> import re
>>> VARIABLE = re.compile(r"\$\{(\w+)\}")
>>> VARIABLE.sub('\\path\\to\\cache', '${defaultBuildDir}/doctrees')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.12/re/__init__.py", line 334, in _compile_template
    return _sre.template(pattern, _parser.parse_template(repl, pattern))
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/re/_parser.py", line 1075, in parse_template
    raise s.error('bad escape %s' % this, len(this)) from None
re.error: bad escape \p at position 0
```

Calling `re.escape` on the replacement ensures that characters like
backslashes are escaped correctly

```python
>>> VARIABLE.sub(re.escape('\\path\\to\\cache'), '${defaultBuildDir}/doctrees')
'\\path\\to\\cache/doctrees'
>>>
```

When `manager.get_client` is called many times in quick
succession (such as on server restart with N files open) this can fool
the `SphinxManager` into creating multiple client instances for a
given configuration scope.

By storing a ``None`` at the relevant scope we allow the SphinxManager
to detect that the scope has already been handled, preventing the
spawning of duplicated client instances.

This should, finally, fix the flaky test issue (#859)

For some reason, the object representation of the same URI is not stable
leading to synchronised scrolling breaking after scrolling the preview
window.

Instead, compare the string representation of the uris which should
work around the differences that should not matter.

As part of its initial setup, the injected `webview.js` script now
rewrites any `a.internal` links to include the port number of the
current websocket connection. This ensures that as the user navigates
by clicking on links on the page the websocket connection to the
language server is preserved.

Also by doing an initial scroll sync on page load, this ensures that
the editor is kept in sync with the change! There is a chance for this
to be a bit flaky as this in direct conflict with the initial sync an
editor might want to make if it initiates the preview of a page.

By introducing a small delay on the sync made by the webview, we are
relying on the editor winning the race and getting its message in
first... I'm sure that will never cause an issue in the future!

In addition to running the preview uri from the server through `vscode.env.asExternalUri`
we need to make sure that the CSP for the embedded iframe is given the correct origin.

The injected `webview.js` script now assumes that the `ws` query
parameter contains the entire URI to use when creating the websocket
connection

Bumps [ovsx](https://github.com/eclipse/openvsx/tree/HEAD/cli) from 0.9.4 to 0.9.5.
- [Release notes](https://github.com/eclipse/openvsx/releases)
- [Changelog](https://github.com/eclipse/openvsx/blob/master/cli/CHANGELOG.md)
- [Commits](https://github.com/eclipse/openvsx/commits/v0.9.5/cli)

---
updated-dependencies:
- dependency-name: ovsx
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.6.0 → v5.0.0](pre-commit/pre-commit-hooks@v4.6.0...v5.0.0)
- [github.com/astral-sh/ruff-pre-commit: v0.6.5 → v0.6.9](astral-sh/ruff-pre-commit@v0.6.5...v0.6.9)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.23.1 to 0.24.0.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.23.1...v0.24.0)

---
updated-dependencies:
- dependency-name: esbuild
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@vscode/vsce](https://github.com/Microsoft/vsce) from 3.1.0 to 3.1.1.
- [Release notes](https://github.com/Microsoft/vsce/releases)
- [Commits](microsoft/vscode-vsce@v3.1.0...v3.1.1)

---
updated-dependencies:
- dependency-name: "@vscode/vsce"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

The sphinx-agent will no longer crash if the configured environment is
missing an extension. Instead the error is suppressed and the agent
will attempt to report it to the user as a diagnostic

However, the diagnostic will only work if the extensions are declared
in `conf.py` using the "standard" Sphinx format i.e.

```python
extensions = [
    'a',
    'b',
    ...
]
```

If a client provides the `esbonio.sphinx.fallbackEnv`, repurpose the server's Python interpreter
to launch the Sphinx agent.

Most runs conclude on the order 5min +/- 2min, so if we hit the 20min
mark chances are something has hung.

This allows us to parse the file once in a central location

The sphinx agent can now handle the case where the requested
`html_theme` is not available in the environment by suppressing the
raised error, overriding the value of `html_theme` and attempting to
run `Sphinx.__init__` again.