Background information

Currently, the bucket-bar should display anchor positions only from a
_single_ guest frame. This is because there is no merging mechanism for
anchor positions from multiple guest frames.

Before this PR

* The host frame listened for `anchorsChanged` events from
_all_ the guest frames.

* Only _one_ guest frame sent this event. We referred to this guest
  frame as having the 'main' annotatable content.  The 'main'
  annotatable guest frame was identified by not having a
  `subFrameIdentifier` (a configuration option added to a guest frame
  when the Hypothesis client was injected). Hence, the 'main'
  annotatable guest frame was always the frame where the Hypothesis
  loaded initially (in contrast with the injection mechanism).

In this PR

We have reversed the logic of how the `anchorChanged` RPC
events are send and received:

* _Every_ guest frame sends `anchorsChanged` RPC events to the host
  frame.

* The host frame chooses to listen to only _one_ guest frame for the
  `anchorsChanged` RPC events: the guest frame that connects first with
  the host.

For non-VitalSource case, the first guest frame that connects to the
host frame is the one where the Hypothesis client was initially loaded
(doesn't contain `subFrameIdentifier` option).

For the VitalSource, because of #4176, there is no guest frame in the
host frame. This allows the guest frame in the book content, where the
Hypothesis client was injected, to send anchor positions, and positions
to be reflected in the host's bucket-bar.

On #4069, we introduced a small improvement when hovering a left-pointed
bucket: focus the corresponding annotation card, in addition to the
anchor's highlight.

In this PR, we introduce the same improvement to the up and down-pointed
buckets.

In addition, I have realised we handled `onBlur` but not `onFocus`
events. I have added more complete support for keyboard navigation.

I substituted `onMouseMove` for `onMouseEnter` because it is triggered
less frequently.

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

In order to not create an unnecessary `Guest` instance in the
VitalSource container we needed to do the following:

* The `VitalSourceContainerIntegration` is stripped down and converted
  to a class, `VitalSourceInjector`, that does not implement the
  Integration interface but is only responsible for injecting the client
  into content frames.

* The host frame checks the VS frame role and either constructs a Guest
  or sets up the `VitalSourceInjector` as appropriate.

* The `HypothesisInjector`-related logic in `Guest` is extracted out of
  that class and set up in the annotator entry point instead.

Refactor applied design and layout for ModerationBanner to fix
regressions and bring component into more standard design patterns.

To allow for proper alignment of child elements using `rem` units,
adjust a couple of outer padding values for `Thread` and `ThreadCard`

Later we will convert `Thread` and `ThreadCard` to `rem`s and tailwind,
but that is a separate task.

When the sidebar is connected to multiple guest frames it will send all
incoming annotations to all frames. The result is typically that the
annotation will anchor in one frame and orphan in the others. Depending
on what order this happens in, the annotation will non-deterministically
show up as an Annotation or Orphan in the sidebar.

In order to determine which frames an annotation should be sent to in
all cases, we'd either need the backend to return information about which
search URIs an annotation matches or make a separate search request for
each frame and record the associated frame with the results. This
will require some significant refactoring of the annotation search
service.

As an interim step, make `FrameSyncService` send annotations only to a
single frame based on matching URL, with a fallback to sending to the
main frame if there is no exact match. This will work as expected for
most pages, and is at least deterministic when it does fail. When we
have a solution for being able to match annotations to frames more
generally, we can adapt this code to use it.

This is a partial solution to https://github.com/hypothesis/client/issues/3992.

Change how the guest notifies other frames, specifically the sidebar and host,
when it is unloaded. The host and sidebar now receive a `frameDestroyed` message
from the corresponding guest port, which allows them to easily close the right
port and remove it from the list of active guest ports.

Due to a Safari bug (see code comments) we can't send the `frameDestroyed`
messages from the guest frame while it is being unloaded. However it is possible
to first transfer the port to the host frame and then have the host frame send
the message on the same port. I also tried sending the message from the guest
frame, and then transferring the port to the host frame but that didn't work.
This workaround has the advantage that it is transparent to the receiver of the
`frameDestroyed` message.

This change is also a step towards possibly not relying on user-provided guest
frame identifiers in the sidebar, which only become available once the
`documentInfoChanged` call has been received. Instead the sidebar could
use its own internal IDs for guest frames, avoiding the possibility for
conflicts.

Changes in detail:

 - Add `disconnect` method to PortRPC

 - When guest is unloaded, transfer ports to the host frame in a
   `hypothesisGuestUnloaded` message, and make the host frame dispatch
   `frameDestroyed` calls on these ports.

 - Handle `frameDestroyed` in sidebar by closing port, removing it from
   the active guest list and removing the associated frame from the
   store

 - Handle `frameDestroyed` in host frame by closing port and removing it
   from the active guest list

Unless the actual name is really verbose or conflicts with another variable, we prefer to avoid import aliases.

Made some very minor changes to avoid import aliases.

This is the convention that I followed to export objects in the
`src/sidebar/store/modules`:  name of the file plus the word `Module`. For example, `direct-linked.js` exports `directLinkedModule`.

The unused type referred to a class that has been deleted.

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

The functionality to compute the buckets has been split in two steps:

1. Guest frame computes and sends a list of the anchors's top/bottom
   positions with the `anchorsChanged` RPC event.

2. In the host frame, `BucketBar` uses the list anchor's positions to
   compute the buckets.

There is one issue with the current approach: if an iframe doesn't cover
the entire host frame's viewport buckets can appear offset.

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.1062.0 to 2.1066.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.1062.0...v2.1066.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 [@sentry/cli](https://github.com/getsentry/sentry-cli) from 1.72.0 to 1.72.1.
- [Release notes](https://github.com/getsentry/sentry-cli/releases)
- [Changelog](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md)
- [Commits](https://github.com/getsentry/sentry-cli/compare/1.72.0...1.72.1)

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

Bumps [sinon](https://github.com/sinonjs/sinon) from 12.0.1 to 13.0.0.
- [Release notes](https://github.com/sinonjs/sinon/releases)
- [Changelog](https://github.com/sinonjs/sinon/blob/master/docs/changelog.md)
- [Commits](https://github.com/sinonjs/sinon/compare/v12.0.1...v13.0.0)

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

Bumps [rollup](https://github.com/rollup/rollup) from 2.66.0 to 2.66.1.
- [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.66.0...v2.66.1)

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

Bumps [karma](https://github.com/karma-runner/karma) from 6.3.11 to 6.3.12.
- [Release notes](https://github.com/karma-runner/karma/releases)
- [Changelog](https://github.com/karma-runner/karma/blob/master/CHANGELOG.md)
- [Commits](https://github.com/karma-runner/karma/compare/v6.3.11...v6.3.12)

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