When the LMS app starts it loads Via and the client concurrently with
creating the group(s) for the current course/sections and provides the
groups to the client asynchronously when ready.

Previously when loading groups in this context the client would fetch
groups from h, then wait for the group IDs to be returned from the LMS
app and filter the list of loaded groups by those IDs. There was a race
condition here in that the client may end up fetching groups from h
before they have been created by the LMS backend.

Additionally the error handling was poor if some or all of the group IDs
returned LMS app failed to load. The user could see just a blank state
with no error notice.

This PR resolves these issues by splitting the `groups.load()` method which
is called on startup to load groups into two separate code paths, one
for the case where the annotation service configures the client to load
specific groups and the other for the default case where the client
loads groups associated with the current user, current document and
direct links.

When specific groups are configured, the client will wait for those IDs
to be available before loading only those groups from the API. If some
of the groups fail to load, an error notice will be shown but any other
groups which did load will still be shown.

A potential issue with this new approach is that we are making one HTTP
request per group to load, although all requests happen concurrently and
we are using HTTP/2. This may be slower if there are a large number of groups.

Fixes #2162