We're now using a HTMX request with a reply status 200, and that means
returning an empty response will remove whatever is in the target. We
fix this by simply returning the target collection name again.

This reduces the time necessary for the volume detail page to come up.

This is equivalent to the “Cribs” tab on dance list details pages, and
reuses the same underlying machinery. There has been some refactoring
of that underlying machinery to accommodate dance list volumes.

This is somewhat simpler than the `VisibleManager` for dance lists and
volumes because there are no public collections.

It also turns out that `DanceList` and `DanceListVolume` can share a
`VisibleManager`, which simplifies the code somewhat.

This is after we upgrade `DanceList.objects.visible()` to include the
patch from the previous changeset that fixes the weird multiplication
of lists in the result.

The base queryset for the dance list “list view” looked like
```
DanceList.objects.filter(
    Q(visibility=LV_PUBLIC)
    | (Q(visibility=LV_GROUP) & Q(group__user=self.request.user))
    | (Q(visibility=LV_PRIVATE) & Q(owner=self.request.user))
)
```
This resulted in a very weird error where a public dance list that
still had a group attached appeared in the list display several times,
because the Django ORM translated this into something like
```
SELECT …
FROM "db_dancelist"
  LEFT OUTER JOIN "auth_group" ON ("db_dancelist"."group_id" = "auth_group"."id")
  LEFT OUTER JOIN "auth_user_groups" ON ("auth_group"."id" = "auth_user_groups"."group_id")
WHERE ("db_dancelist"."visibility" = 3
  OR ("db_dancelist"."visibility" = 2 AND "auth_user_groups"."user_id" = 1)
)
```
i.e., the second `LEFT OUTER JOIN` resulted in as many rows as there
were members in the associated group, and all of them were picked for
the result because the list visibility was `LV_PUBLIC` (3) and they
matched the first `WHERE` clause.

We're changing this to
```
DanceList.objects.filter(
    Q(visibility=LV_PUBLIC)
    | Q(visibility=LV_GROUP,
        group__in=Subquery(self.request.user.groups.values("id")))
    | Q(visibility=LV_PRIVATE, owner=self.request.user)
)
```
which doesn't do a `JOIN` on the `auth_user_groups` table. (The
`Subquery()` doesn't depend on the content of the row being considered
but PostgreSQL is smart enough to lift it out of the loop.)

1. Fix key of `--dry-run` option.
2. Update `seen` count of people.
3. Flush progress output so it is actually being displayed.

This code fails if the user is not authenticated but it is not needed
in the first place anymore.

This used a wrong field specification.

This looked really terrible on the production system.

Not just the ones owned by the current user.

This sucks to a certain degree because of the code duplication. It is,
however, difficult to refactor without introducing circular imports.

This should make it more obvious when overview results are restricted
to the content of a collection.

This was inadvertently left out when adding music collections.

This should make navigation a lot easier because the table doesn't
reset to page 1 on the default sort.

This includes refactoring the collection dropdown menu into an
inclusion tag, because DRY.

If a dance occurs in multiple publications in a collection, display
one result line with multiple publications rather than multiple result
lines with one publication each.

This fixes a weird bug in the complex dance search function where, if
the “RSCDS dance” box was checked, there would be as many copies of
the dance in the result as there are RSCDS publications it appears
in (which for some dances can be very many). Essentially, instead of a
simple `.filter(publications__rscds=True)` operation, we need to
annotate the queryset with a Boolean property that says whether any of
the publications of the dances are RSCDS publications, and then filter
on that.

This is so the correct current collections and dance list will be
displayed by the base template.

This introduces the concept of a crib sheet “style”, which is a
combination of inclusion/exclusion options. It is possible to select
one of a number of predefined styles, or assemble one's own, which can
be saved in the session and will serve as the default style from then
on as long as the session lasts.

If a collection is active when you're generating a crib sheet, then
optionally references to relevant publications in that collection will
be added to dance/extra/alternative items.

This is mainly interesting for the shelf codes so it becomes easier to
pull the original publications in preparation for a class.

This is to make life easier for me when integrating books from
Meinhard's library into my own.

We make sure that when looking at a dance list volume:

- Only those lists are displayed that the current user would otherwise
  be allowed to see, according to the privacy settings on the lists.

- The “Dances” and “Publications” tabs only contain information about
  dances from those lists.

This makes it impossible for people to (partially) infer the content
of private dance lists from information on the dance list volume
detail page.