Switch client to a read-only state when user cannot post to current group

_This is a cleaned up version of https://github.com/hypothesis/product-backlog/issues/489 reflecting the outcome of design feedback and developer elaboration._

If the user selects a restricted group which they are not a member of, the client should prevent them from creating annotations and indicate that the current group is read-only.

## Acceptance criteria

As a user, when I visit a page and select a group which I cannot post to (eg. because it is a restricted group and I am not a member):

- [ ] The "Adder" toolbar displays in a read-only state where: 1) the "Annotate" button is replaced with a "View annotations" button which opens the sidebar but does not create a new annotation, 2) the "Highlight" button is disabled, 3) The tooltips are different. See mocks below.
- [ ] The adder changes in the previous AC also apply in iframes embedded on a page
- [ ] The "New note" button is not available inside the sidebar, when that feature is enabled, and the "Reply" button is not shown on individual annotation cards
- [ ] The "New note" button is not shown in the sidebar's toolbar
- [ ] A badge appears at the top of the sidebar indicating that it is read only. See https://github.com/hypothesis/product-backlog/issues/552

### Read-only adder mocks


### Read-only indicator mocks

There is an indicator at the top of the sidebar to show that the current group is read-only. There are various states this can be in depending on available space. See https://github.com/hypothesis/product-backlog/issues/552 for full details.


## Implementation

I think the implementation work here breaks down roughly as follows:

- [ ] In the API, communicate to the client whether the user can post to a given group. Note that we cannot just use `group.type === "restricted"` because that is a property of the group, whereas ability to post depends on the user's permissions within the group
- [ ] Monitor the read-only state of the focused group in the sidebar and communicate it to the host page.
- [ ] Communicate the read-only state of the focused group to any instances of the client loaded in iframes on the host page
- [ ] Add a 'read-only' state to the toolbar in the host page and make that reflect the read-only state communicated from the host page, following the mocks in the issue description
- [ ] Add a 'read-only' state to the "Adder" toolbar and make that reflect the read-only state communicated from the host page, following the mocks in the issue description
- [ ] Remove or disable the "New note" button in the sidebar when the current group is read-only, as well as the "Reply" button on individual annotation cards
- [ ] Add a "Read only" badge to the sidebar and make that reflect whether the focused group is read-only. This is captured in the separate card at https://github.com/hypothesis/product-backlog/issues/552

Since several of these steps depend on the focused group, it would be helpful if that state were moved from the groups service in `services/groups.js` to the store as per [this recent ADR](https://github.com/hypothesis/client/blob/master/docs/developers/arch/adr-003.md).

Start by reading services/groups.js and docs/developers/arch/adr-003.md to understand how focused-group state is represented. Trace the API-to-client and host-page communication paths, including iframe instances, then review the acceptance criteria and linked read-only badge issue. Done means all listed read-only adder, sidebar, reply, iframe, and badge behaviors are covered.

Written by the indexing model from the issue text.