Change the logic for making highlights visible when creating a new
annotation, so that it works if the annotation was created in a non-host
frame.

This is done by moving the logic from the `beforeAnnotationCreated`
handler in the Sidebar class, which was only called for annotations in
the host frame, to the `beforeCreateAnnotation` handler in
FrameSyncService, which is called for all frames. The sidebar app will
then send a request to show highlights to the host frame, which will
update the sidebar's controls and then relay the request to guest
frames.

Make the client's highlight visibility state work in a sane way in
scenarios where there are multiple guests, or the main guest frame is not the
host frame. Previously there were several problems in these scenarios:

 - It was unclear which component of the application "owned" the
   highlight visibility state. The state in the sidebar could be changed
   as a result of the `highlightsVisibleChanged` event emitted by a
   Guest, as well as the user toggling highlight controls in the
   sidebar.

 - In the sidebar's `open` and `close` methods it directly set the
   highlight visibility in the main guest if the `showHighlights`
   setting was set to `whenSidebarOpen`. This meant that it didn't work
   for guests that were not in the main frame.

 - Guest frames could be configured with different `showHighlights`
   settings. In this case it was unclear what should happen.

This commit resolves this by making the `Sidebar` class in the host
frame the central owner of this state. It handles configuring the
initial state based on the `showHighlights` configuration setting, and
reflecting this state to the sidebar application which in turn reflects
it to guest frames. The initial visibility of highlights in a guest
frame is synchronized with this state when the guest frame connects to
the sidebar. This state is updated by the `Sidebar` class when:

 - The user toggles the highlight visibility control in the sidebar
 - A new highlight or annotation is created in a guest frame
 - The sidebar opens and closes, if the `showHighlights` configuration
   was set to `whenSidebarOpen`

Additionally the inconsistency of `setHighlightsVisible` vs
`setVisibleHighlights` in identifier and event names has been resolved by
using `setHighlightsVisible`/`highlightsVisible` everywhere.

Part of https://github.com/hypothesis/client/issues/3798

There was an action to set this state but it was never read anywhere.

Co-authored-by: Robert Knight <robertknight@gmail.com>

I have created type definitions for all the event names that are sent
across the different frames using various `Bridge`s. It is based on the
previous `bridge-events.js`. I broke down the events in four sections
based on the direction of the messages:

* guest -> sidebar events
* host -> sidebar events
* sidebar -> guest/s events
* sidebar -> host events

For those events that didn't have a description I added one.

This is more stringent and less verbose than the previous lookup system.

Move the responsibility for opening the sidebar when there is a draft to
edit from the guest into the sidebar's `FrameSyncService`.

The initial motivation for this was to make the logic in the
`beforeAnnotationCreated` event handler in the `Sidebar` class work if
the annotation is created in a non-host guest frame. The plan was to
make the sidebar send an `openSidebar` request with custom options that
would trigger the logic that used to be in the `beforeAnnotationCreated`
event handler.

However it appears that focusing the sidebar frame is no longer necessary. In my
testing the input field in the sidebar was successfully focused regardless
of whether `iframe.contentWindow.focus()` was called or not. Therefore I
have just removed the handler.

Even though the original need no longer exists, moving the logic still
seems sensible because logically it is the sidebar application that
knows it is awaiting user input after a new draft is created. It also means that
if we do find a need to re-introduce the frame-focusing logic that used
to be in the `beforeAnnotationCreated` handler, we can do so in a way
that works with annotations created in non-host frames.

The initial un-hiding and opening of the sidebar was previously
triggered by a `panelReady` event emitted by the Guest in the host frame
when it connects.

As part of eliminating the need for the host frame to also be a guest,
change the initial sidebar open to use the `Sidebar.ready` promise
instead, which is resolved when the sidebar applicaiton sends a
`hypothesisSidebarReady` notice to the `Sidebar` app.

Part of https://github.com/hypothesis/client/issues/3798

Fix `gulp test --watch`. See https://github.com/hypothesis/frontend-shared/pull/214.

Streamline the Karma configuration to remove obsolete settings and make
it easier to see what non-default configuration we have supplied.

 - Remove `grep` option handling. The `--grep` option when running tests
   is now used in gulpfile.js to select which _files_ are included in
   the test.

 - Remove comments which add little value

 - Remove config settings that just set default values which are not
   expected to change in future

Bumps [rollup](https://github.com/rollup/rollup) from 2.47.0 to 2.58.0.
- [Release notes](https://github.com/rollup/rollup/releases)
- [Changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rollup/rollup/compare/v2.47.0...v2.58.0)

---
updated-dependencies:
- dependency-name: rollup
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [babel-plugin-istanbul](https://github.com/istanbuljs/babel-plugin-istanbul) from 6.0.0 to 6.1.1.
- [Release notes](https://github.com/istanbuljs/babel-plugin-istanbul/releases)
- [Changelog](https://github.com/istanbuljs/babel-plugin-istanbul/blob/master/CHANGELOG.md)
- [Commits](https://github.com/istanbuljs/babel-plugin-istanbul/compare/v6.0.0...v6.1.1)

---
updated-dependencies:
- dependency-name: babel-plugin-istanbul
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@rollup/plugin-commonjs](https://github.com/rollup/plugins/tree/HEAD/packages/commonjs) from 19.0.0 to 21.0.0.
- [Release notes](https://github.com/rollup/plugins/releases)
- [Changelog](https://github.com/rollup/plugins/blob/master/packages/commonjs/CHANGELOG.md)
- [Commits](https://github.com/rollup/plugins/commits/commonjs-v21.0.0/packages/commonjs)

---
updated-dependencies:
- dependency-name: "@rollup/plugin-commonjs"
  dependency-type: direct:development
  update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.1004.0 to 2.1010.0.
- [Release notes](https://github.com/aws/aws-sdk-js/releases)
- [Changelog](https://github.com/aws/aws-sdk-js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-js/compare/v2.1004.0...v2.1010.0)

---
updated-dependencies:
- dependency-name: aws-sdk
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@rollup/plugin-node-resolve](https://github.com/rollup/plugins/tree/HEAD/packages/node-resolve) from 13.0.0 to 13.0.5.
- [Release notes](https://github.com/rollup/plugins/releases)
- [Changelog](https://github.com/rollup/plugins/blob/master/packages/node-resolve/CHANGELOG.md)
- [Commits](https://github.com/rollup/plugins/commits/node-resolve-v13.0.5/packages/node-resolve)

---
updated-dependencies:
- dependency-name: "@rollup/plugin-node-resolve"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [mocha](https://github.com/mochajs/mocha) from 9.1.2 to 9.1.3.
- [Release notes](https://github.com/mochajs/mocha/releases)
- [Changelog](https://github.com/mochajs/mocha/blob/master/CHANGELOG.md)
- [Commits](https://github.com/mochajs/mocha/compare/v9.1.2...v9.1.3)

---
updated-dependencies:
- dependency-name: mocha
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [sass](https://github.com/sass/dart-sass) from 1.42.1 to 1.43.2.
- [Release notes](https://github.com/sass/dart-sass/releases)
- [Changelog](https://github.com/sass/dart-sass/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sass/dart-sass/compare/1.42.1...1.43.2)

---
updated-dependencies:
- dependency-name: sass
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@rollup/plugin-alias](https://github.com/rollup/plugins/tree/HEAD/packages/alias) from 3.1.2 to 3.1.5.
- [Release notes](https://github.com/rollup/plugins/releases)
- [Changelog](https://github.com/rollup/plugins/blob/master/packages/alias/CHANGELOG.md)
- [Commits](https://github.com/rollup/plugins/commits/alias-v3.1.5/packages/alias)

---
updated-dependencies:
- dependency-name: "@rollup/plugin-alias"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [typescript](https://github.com/Microsoft/TypeScript) from 4.4.3 to 4.4.4.
- [Release notes](https://github.com/Microsoft/TypeScript/releases)
- [Commits](https://github.com/Microsoft/TypeScript/compare/v4.4.3...v4.4.4)

---
updated-dependencies:
- dependency-name: typescript
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [core-js](https://github.com/zloirock/core-js) from 3.18.2 to 3.18.3.
- [Release notes](https://github.com/zloirock/core-js/releases)
- [Changelog](https://github.com/zloirock/core-js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/zloirock/core-js/compare/v3.18.2...v3.18.3)

---
updated-dependencies:
- dependency-name: core-js
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@rollup/plugin-replace](https://github.com/rollup/plugins/tree/HEAD/packages/replace) from 2.4.2 to 3.0.0.
- [Release notes](https://github.com/rollup/plugins/releases)
- [Changelog](https://github.com/rollup/plugins/blob/master/packages/replace/CHANGELOG.md)
- [Commits](https://github.com/rollup/plugins/commits/wasm-v3.0.0/packages/replace)

---
updated-dependencies:
- dependency-name: "@rollup/plugin-replace"
  dependency-type: direct:development
  update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>

Convert the Rollup config files to have a `.mjs` extension so that Node
can natively load them as ES modules and then load them using
`import(...)` rather than the `loadConfigFile` helper.

This avoids a deprecation warning when importing `rollup/dist/loadConfigFile`:

```
(node:21339) [DEP0148] DeprecationWarning: Use of deprecated folder
mapping "./dist/" in the "exports" field module ...
```

This also makes the way the config file is loaded more transparent, since its
just a regular dynamic import.

The downside of this change is that we don't get a `warnings` object
back to print warnings that occur during bundling.
Instead have to pass an `onwarn` handler to `rollup.{rollup, watch}`.

Use the shared utility classes; remove local implementations

Util styles should come after component styles

This should make it easier to speed up test runs in future by
pre-building npm dependencies into a separate bundle which the main test
bundle can import from.

The CommonJS plugin is the second most expensive transform after Babel.
Since all of our own code uses ES modules, limit it to npm dependencies
to speed up the build.

In tests the Babel transform has also been moved last so that additional
code it generates is not unnecessarily processed by subsequent plugins.

Combined these changes speed up a build of the full test bundle by ~4s.

This fixes a slow test on this branch, which appears to be caused by an
interaction between using `postMessage` to serialize native Error
objects and the `source-map-support` Karma plugin that we use.

Sending native Errors via `PortRPC` currently doesn't work in all
browsers so I expect we'll want to implement our own serialization of
errors in `PortRPC` to work around that. That can also work around the
`source-map-support`/`postMessage` issue in Chrome in future.

To move the Browserify => Rollup conversion forwards, this commit just
changes the test to use an Error-like rather than actual Error object.

`sinon` is exposed as a global in the test environment so it doesn't
need to be imported. Additionally some of the dependencies of Sinon
(samsam, nise) cause warnings about circular dependencies and use of
`eval` when bundled by Rollup.

Add comments to clarify a few things about the way the tests are built
and run.

Due to pre-existing `<script>` tags on third-party websites that load
the client's boot script, via https://hypothes.is/embed.js, we need to
keep generating it as a classic rather than ES module script for now.

This prevents a warning from Rollup about use of `this` outside a class
or (non-arrow) function in development builds, due to the way Babel
compiles JSX expressions [1]. Moving top-level code into a function is
also useful in case we ever want to write tests for it.

[1] https://github.com/babel/babel/issues/9149

Since the exclusion is no longer triggered by logic in the source code,
add a note about where this happens.

Make conditional exclusion of modules work the same way in the app
bundle as in the tests bundle.

Fix an occasional error from Gulp about a missing `boot.bundle.js` file
when running `make dev` for the first time after `make clean`. This can
happen if `updateManifest` runs before Rollup has generated
`boot.bundle.js`. The error can be safely ignored as `updateManifest`
will be re-run after `boot.bundle.js` is generated.

See https://github.com/hypothesis/browser-extension/pull/681

Replace Browserify with Rollup as a module bundler. This brings several
advantages:

- It is a more modern bundler that has better support in the ecosystem,
  more active maintenence, fewer dependencies and is easier to write plugins for.
  The core team also maintain most of the plugins that we need.

- It has native support for modern platform features like ES modules,
  including dynamic import for lazy-loading of functionality.

- It generates smaller bundles due to its ability to do tree shaking and scope hoisting.

The new bundles are generated as ES modules rather than UMD / IIFE bundles.
Our target browsers now all support ES modules and this will enable us to use
native static/dynamic imports for code splitting or lazy-loading of
functionality in future.

The initial Rollup build generates one bundle per application (boot script,
annotator, sidebar). This simplifies the build process and minimizes production
bundle size, at the cost of making incremental updates during development
slightly slower.

Build performance is currently similar to or a little slower than Browserify.
We can optimize this by adding caching of transforms (mainly Babel) and
pre-building of a vendor bundle containing large dependencies.

As part of changing the bundler this also changes how the code is packaged
for tests.  We now do the bundling ourselves rather than using a Karma
integration. This makes it much easier to inspect the processed code and fix
problems. It also makes it easier to optimize the bundle building in future.