Add a utility function that wraps `fetch` to throw more consistent and
useful exceptions if the request fails, making downstream handling
easier.

- Error messages thrown by failed `fetch` requests are unhelpful for
  downstream consumers. There is no specific Error subclass and the
  error messages vary depending on cause and browser.

- Parsing the JSON response from a request with `Response.json()` can
  fail if the request has a success status and the error messages also
  vary by browser.

The `fetchJSON` utility throws a `FetchError` error if either of the
above failures occurs or if the response code indicates a failure.

Also move `$imports` to end per convention.

Following PR feedback, document the return type of `_getAccessToken`
explicitly and make the error thrown in the event of a non-2xx response
more informative.

Now that we have good support for mocking imports in tests, we can use
that to mock `generateHexString` calls in `OAuthClient` rather than
needing to have a test seam in the class.

This improves test coverage slightly.

Prepare for upcoming improvements to handling of network errors across
the client by refactoring some `fetch` requests and error handling in
OAuthClient.

 - Extract duplicated logic for fetching an access token into a
   `_getAccessToken` method.

 - Create a `TokenError` class to wrap all errors that may be thrown
   when fetching or revoking an access token. This makes it easier for
   downstream consumers to handle such errors in a uniform way.

   The `TokenError` error links to the network or other error that
   caused it via the `cause` property, following the convention
   currently being standardized in https://github.com/tc39/proposal-error-cause.

`HypothesisInjector._injectIntoFrame` checked that the DOM of the
document was ready, however, that was wrapped in
`FrameObserver._addFrame` which also checked the readiness of the
document.

I decided to leave only one check.

I believe it would be faster to rely on `DOMContentLoaded` event
(`isDocumentReady` function). This event triggers when the DOM is fully
loaded and parsed but without waiting for the stylesheets, images, and
subframes to finish loading [1].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event

I believe we know what was causing the issue in ThreadList where an
effect callback was sometimes called with closed-over variables which
did not match the most recent render. See [1] for details. The issue
really needs to be resolved in a more general way than trying to work
around it in individual components.

This commit removes code added for debugging this and also adds a check
for a legitimate way (ie. without anything going wrong inside Preact)
that the problem could occur, although it should never happen in the
actual app as we never render `ThreadList` in a container that is
disconnected from the document.

[1] https://github.com/hypothesis/client/pull/3665#issuecomment-895857072

It appears that an effect in `ThreadList` can be called (see [1]) when the
variables captured by the effect do not match the current rendered
output. Add some debug code to verify more directly that this is the
case.

[1] https://sentry.io/organizations/hypothesis/issues/2562006490/

The test that used this utility function was failed randomly. It seems
that the `onConnect` callback is not always been triggered on the next
JS cycle.

Previously, after `FrameObserver` was constructed it required
`.observe(callback1, callback2)` method to be executed to start the
observation.

With this change the callbacks are provided in the constructor and the
observation starts immediately.

This reflects better the content of the integration test.

Extracted from `CrossFrame` functionality that was related to the
injection of the Hypothesis client into its own class,
`HypothesisInjector`.

In addition, I simplified and modernised the `multi-frame-test.js`.

There are a couple of follow up questions:

- should the utility functions in `frameUtil` be consolidated in the
  `hypothesis-injector.js` file? Most of this functionality is only used
  in the `HypothesisInjector` or `FrameObserver` classes.

- should `HypothesisInjector` be combined with `FrameObserver`?

Bumps [puppeteer](https://github.com/puppeteer/puppeteer) from 10.1.0 to 10.2.0.
- [Release notes](https://github.com/puppeteer/puppeteer/releases)
- [Changelog](https://github.com/puppeteer/puppeteer/blob/main/CHANGELOG.md)
- [Commits](https://github.com/puppeteer/puppeteer/compare/v10.1.0...v10.2.0)

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

Bumps [sass](https://github.com/sass/dart-sass) from 1.37.0 to 1.37.5.
- [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.37.0...1.37.5)

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

Since h has very liberal URI parsing compared to the browser's URL
constructor, as well as some completely invalid data on old annotations,
the client needs to handle errors parsing annotation `uri` values.

Surprisingly `annotation-metadata.js` is the only place I found in the
client that attempts to do this, everywhere else is just using the `uri`
field as a string.

Fixes https://github.com/hypothesis/client/issues/3666

Bumps [@babel/preset-env](https://github.com/babel/babel/tree/HEAD/packages/babel-preset-env) from 7.14.9 to 7.15.0.
- [Release notes](https://github.com/babel/babel/releases)
- [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md)
- [Commits](https://github.com/babel/babel/commits/v7.15.0/packages/babel-preset-env)

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

Bumps [@octokit/rest](https://github.com/octokit/rest.js) from 18.7.2 to 18.9.0.
- [Release notes](https://github.com/octokit/rest.js/releases)
- [Commits](https://github.com/octokit/rest.js/compare/v18.7.2...v18.9.0)

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

Bumps [redux](https://github.com/reduxjs/redux) from 4.1.0 to 4.1.1.
- [Release notes](https://github.com/reduxjs/redux/releases)
- [Changelog](https://github.com/reduxjs/redux/blob/master/CHANGELOG.md)
- [Commits](https://github.com/reduxjs/redux/compare/v4.1.0...v4.1.1)

---
updated-dependencies:
- dependency-name: redux
  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.16.0 to 3.16.1.
- [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.16.0...v3.16.1)

---
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 [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.958.0 to 2.963.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.958.0...v2.963.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 [@babel/core](https://github.com/babel/babel/tree/HEAD/packages/babel-core) from 7.14.8 to 7.15.0.
- [Release notes](https://github.com/babel/babel/releases)
- [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md)
- [Commits](https://github.com/babel/babel/commits/v7.15.0/packages/babel-core)

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

Bumps [@sentry/browser](https://github.com/getsentry/sentry-javascript) from 6.10.0 to 6.11.0.
- [Release notes](https://github.com/getsentry/sentry-javascript/releases)
- [Changelog](https://github.com/getsentry/sentry-javascript/blob/master/CHANGELOG.md)
- [Commits](https://github.com/getsentry/sentry-javascript/compare/6.10.0...6.11.0)

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

Bumps [sinon](https://github.com/sinonjs/sinon) from 11.1.1 to 11.1.2.
- [Release notes](https://github.com/sinonjs/sinon/releases)
- [Changelog](https://github.com/sinonjs/sinon/blob/master/CHANGELOG.md)
- [Commits](https://github.com/sinonjs/sinon/commits)

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

Following our conventions only Preact components should have default
exports.

In addition, the class it is now called `PortRPC` to follow our
conventions.

The `methods` argument constructor could be an object that uses `this`.
However, we do not rely in this feature, so I am suggesting to simplify
the execution of the callbacks.

After #3611 there is no more need to support `window.postMessage` on `RPC` and `Bridge` classes.

This is a old pattern. `Element.remove` is currently supported by our
test environment.

Add code to debug an error [1] triggered during an effect in the
`ThreadList` component.

When the effect is run, an attempt to get a reference to a DOM node
rendered by the component using `getElementById` is failing. This could
be because:

 - The component has been unmounted (I didn't think effects could run
   after unmounting, but I'm not certain)
 - The component has been rendered but the DOM has not yet been attached
   to the document
 - The `visibleThreads` value captured by the effect does not match the
   most recently rendered output.

I couldn't reproduce the issue locally. The debugging code added here
should narrow down which of these is happening.

[1] https://sentry.io/organizations/hypothesis/issues/2554918407/

`CrossFrame#call|onConnect|on` are proxies of
`Bridge#call|onConnect|on`.

Instead of duplicating the documentation of `Bridge` methods on
`CrossFrame` we use a `@see`.

We reserve default exports only to Preact components.

The documentation for the `on` and `call` are documented identically as
in the `Bridge` class and use the same nomenclature.

We previously implemented a custom confirm dialog for use in browsers
which disallow use of `window.confirm` in cross-origin iframes (Chrome 9x) but
kept `window.confirm` in other browsers while the design of the new
dialogs was polished.

The polishing has now been done, so this commit switches all confirm
dialogs to use the new dialogs. This makes the experience look better
and be consistent across browsers.

No functional change.

The added type has surfaced that `iframe.contentDocument` could be
`null`. This was no considered before. I didn't deviated from the
original behaviour and I casted the value. If in the future we found
issues we should see those in the Sentry reports.

Add information to Sentry error reports about what JavaScript files were
included on the page.

I have a hypothesis that Sentry issues like
https://sentry.io/organizations/hypothesis/issues/2528337318/events/e176f165836149b99d439fa71e69453c/?project=69811&query=is%3Aunresolved
might be caused by unwanted `<script>` tags injected by extension or the browser.
We try to block most unexpected scripts using strict
Content-Security-Policy settings, but extension and custom
browser-injected scripts may be able to bypass this.