Removing the optional types on `ConfigFlags` lets us remove a few null
suppression errors here and there and removes some `strictNullChecks`
violations as well.

To make it easy to create a correctly-formed `ConfigFlags` object this
also introduces a `createConfigFlags` helper function which takes a
partial `ConfigFlags` object and returns one with default properties
set.

this commit lightly refactors the various karma utilities used by
browserstack tests. the motivation for this effort was STENCIL-433,
wherein we are attempting to stabilize the browserstack tests. there
was an initial belief that some of the flakiness could have been a
result of the contents of these utils. that is not longer suspected -
however, the code changes found in this commit are (subjectively) nice
cleanups to have for future maintainers

STENCIL-433: Stabilize Browserstack Tests

this commit takes the pre-existing browserstack workflow (renamed from
`browserstack.yml` to `test-browserstack.yml`) and splits one job into two:
one for building stencil, and another to build the downstream applications
+ run browserstack

the intent behind this commit is to make re-running browserstack a
faster operation for stencil engineers. rather than waiting
approximately 8 minutes to see if a job passes, we take the flakier of
the two (running browserstack) and move it into its own job. from the
github ui, we can "rerun failed jobs" for this workflow, resulting in a
~3.5 minute turnaround time. this is a part of a larger effort to
stabilize browserstack tests. while this commit doesn't perform any
stabilizations per se, it does help mitigate the time lost due to flaky
tests.

the first job makes use of our pre-existing `build_core` job, which
should meet our requirements for preventing secrets from leaking.
we do still end up with a double build (one in the main ci workflow,
and one here). the good news is that the two builds/caches are isolated
from one another, which means for now we don't have to worry about
race conditions between the Browserstack build and the main one. In the
future, we'd like to see if there's anything that can be done in this regard
(either using the same build step or smarter caching), but at the least
for now this PR moves the needle a little bit closer in the direction of ci
stability (or having a better experience when its flaky)

STENCIL-433 Stabilize Browserstack CI Tests

…3468)

This fixes the typedef file generated for the `index.js` file produced
by `dist-custom-elements`. Previously it was mistakenly assuming that
the path to a component's `d.ts` file could be generated on the basis of
the `tag` set on the component. This _is_ the case if the component's
filename is equal to it's tag, but there is no requirement that that be
the case.

This changes the way that the relative path from
`${outputDir}/components/index.d.ts` to the `.d.ts` file for a specific
component is generated.

Previously we were doing something like:

```ts
${outputDir}/types/components/${component.tagName}/${component.tagName}
```

This doesn't work if a component is saved in
`src/components/button/button.tsx` but has a tag like `custom-button`.
So to fix this we can instead:

- find the relative path from the source root to the component, giving
  us e.g. `components/button/button.tsx`
- join that relative path with the relative path from where `index.d.ts`
  is going to be saved (`${outputDir}/components/index.d.ts`) to the
  directory where types are written (e.g. `${outputDir}/types`)

This will give us an import in `index.d.ts` that looks like:

```ts
export { Button as CustomButton } from '../types/components/button/button.tsx';
```

this commit adds a concurrency string, 'run_browserstack_queue' to the
'run_browserstack' job in ci.

the name for the concurrency field was chosen to:
- make it easily identifiable as a part of running browswerstack
- not overlap with the name of the run_browserstack job completely to
   avoid any confusion when debugging in the future
    
this change prevents a condition in ci where two simultaneous browserstack 
runs are attempted at the same time. stencil's browserstack license only
allows for five parallel runs at a given time. as of the time of this
writing, stencil uses three browsers per run of browserstack. as a
result, two runs of the job will result in requesting more browsers than
our license permits. on the browserstack side, the extra run (number six
of the five) is queued to run once one of the five completes. however,
on the karma side things, we don't have a great way to check for these
queued jobs and poll until one is done. as a result, we experience
timeouts/disconnects with browserstack as a result of waiting for a
browser instance (that's queued) to start up. oftentimes, we hit a
jasmine/karma timeout of ~30_000 milliseconds.
    
with this change, we are able to continue to have the flexibility to
re-run just the browserstack tests, while blocking them from running
when we aren't sure that we can acquire all the necessary instances. it
should be noted that this does not handle cases where a developer is
tunneling into browserstack from their local machine

for mock-doc, `blur()` and `focus()` methods will now dispatch an
event. created `MockFocusEvent` which extends a new 
`MockUIEvent`, which extends the existing `MockEvent`.