web: maintenance: split tsconfig into “base” and “build” variants. (#9036)

* web: fix esbuild issue with style sheets

Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).

Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.

In standard mode, the following warning appears on the console when running a Flow:

```
Autofocus processing was blocked because a document already has a focused element.
```

In compatibility mode, the following **error** appears on the console when running a Flow:

```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
    at initDomMutationObservers (crawler-inject.js:1106:18)
    at crawler-inject.js:1114:24
    at Array.forEach (<anonymous>)
    at initDomMutationObservers (crawler-inject.js:1114:10)
    at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```

Despite this error, nothing seems to be broken and flows work as anticipated.

* web: maintenance.  Split tsconfig into "base" and "build" variants.

This commit creates the now fairly standard split between the tsconfig "build" and "base"
variants.  This split is useful in defining build variants that have a default set of
rules (such as library use, language constraints, and specialized plug-in checks) but
can be varied in "extension" files.

The most common use for this is to allow for IDE-specific versions of tsconfig (which
know only to look for `tsconfig.json`) while enabling providing more comprehensive
variants to build and lint systems.

This commit is intended to enable this behavior so that different versions of Patternfly
can be included in a slow, evolutionary way that won't create too many incomprehensibly
huge reviews in the coming days.

A comparison of the produced configs, derived by `tsc --showConfig`, between this branch
and _main_ show no difference in the output of the complete tsconfig.json used by the
compiler.

---

It annoys me, a *lot*, that Doug Crockford didn't allow comments in JSON files,
and both the NPM folks and the TSC folks have been obstinate in not permitting
alternative formats for their configuration files. This makes it impossible to
comment some of the most important and complicated files in our system.

* Restarted the webui docs folder.  Docs should always live with the project.

* web: prettier has opinions.

web/docs/Changelog.md

@@ -0,0 +1,17 @@
+### 2024-03-26T09:25:06-0700
+
+Split the tsconfig file into a base and build variant.
+
+Lesson: This lesson is stored here and not in a comment in tsconfig.json because
+JSON doesn't like comments. Doug Crockford's purity requirement has doomed an
+entire generation to keeping its human-facing meta somewhere other than in the
+file where it belongs.
+
+Lesson: The `extend` command of tsconfig has an unexpected behavior. It is
+neither a merge or a replace, but some mixture of the two. The buildfile's
+`compilerOptions` is not a full replacement; instead, each of _its_ top-level
+fields is a replacement for what is found in the basefile. So while you don't
+need to include _everything_ in a `compilerOptions` field if you want to change
+one thing, if you want to modify _one_ path in `compilerOptions.path`, you must
+include the entire `compilerOptions.path` collection in your buildfile.
+g