Add a collections field that only curators, librarians, and admin can edit

Collections are composed of pages with lots of carousels made using either a ListCarousel or a QueryCarousel.

We need a way to call a specific set of work identifiers in a carousel macro, but there are downsides to both (a) using ListCarousel to call a list, and (b) giving a set of works a specific subject and calling that subject with QueryCarousel.

### Downsides of ListCarousel

Making a list for each carousel can work great, but it does have some significant downsides:

1. The person who owns the list might move or leave or die or vanish. Now we have an account access problem.
2. Only one person can really manage a carousel at a time, unless we create a curator account to make lists and share the password, which has security implications.
3. If we were sharing a curator account, now we curators would be managing two accounts (personal and curator) and can't trace back who made what merges or whatever in the curator account. It would get complicated and messy.
3. Carousels might contain only a few items, which means a curator might end up with tons of lists on their personal account, which gets in the way of a tidy profile page.

### Downsides of QueryCarousel

1. We curators have been finding subjects really useful in creating collections using QueryCarousels, but anyone can edit or add to the subjects on a work record. Also, sometimes we would like to use subjects that might look weird or awkward to a patron who doesn't have the context, so they might try to be helpful and delete it.
2. What is a subject anyway? Is it a tag? Is it a WorldCat / Library Official Subject? How many should a work have? Is there a limit to how many a work should have? Those are all great questions! We should talk about them! But right now, we curators just want to make collections full of carousels.

### Proposal

Let's add a Collections field in the Work Details tab on a work record. Like so:


Maybe that field could only be rendered for a logged-in user who is also a curator, admin, or librarian.

The items would need to be searchable by the QueryCarousel, perhaps like this, replacing "subject" with "collection" but otherwise exactly as how we build collections from subject queries now:

```
{{QueryCarousel('collection:"LGBTQ novels"', search=False, has_fulltext_only=False, sort='scans, editions', key="lgbtq_novels")}}
```

Because we would be using the Collections field exactly as we are using subjects, it wouldn't need to be anything other than text strings, like subjects.

### Benefits

1. Curators don't have to fill up our personal accounts with tons of tiny lists
2. Curators don't have to maintain separate accounts that might get complicated
3. No separate, shared curator account is required
4. Any curator (or above) can edit any collection string, so collections can be inherited or transferred or maintained independent of user accounts. Part of curator training will be "don't change existing collection strings if they're not yours."
5. The Collections field on the work record could be invisible (and therefore not be confusing) to patrons
6. Giving curator permissions to a librarian-in-training already gives access to edit pages, and now could also give access to this field without giving any other permissions that might be more risky, such as merging.

### Concerns

1. I assume this is not a super trivial add, since this would effectively duplicate subjects wherever subjects are, with the exception of subjects pages. It would be cool to add Collections as a field to the Advanced Search page, but almost certainly no need to add it to the main search bar dropdrown.
2. Not sure what should happen if a patron goes to https://openlibrary.org/collections/lgbtq_novels. Maybe just return the search results you'd 'return if they searched 'lgbtq novels' in the Advanced Search page.
3. The ability to drop a /collections/string in solr reindex would be as handy as when we have to throw /subjects/string in there, to force a reindex.
4. At minimum, I just want to use QueryCarousel to display the results of a field that only curators and above can edit.

### Stakeholders

@libjenner

Start by tracing the Work Details tab, QueryCarousel collection queries, and the existing subject search and reindex paths. Define the permission checks, storage and indexing behavior, and any /collections or Advanced Search behavior before implementation; done means curators, librarians, and admins can edit the field and QueryCarousel can retrieve it.

Written by the indexing model from the issue text.