Indexing MEI files for folios that don't exist in CantusDB is hacky

[dchiller]

When chants end on a folio where no other chants begin, the folio does not exist in CantusDB but does have an MEI file. Folio A14r in Salzinnes is a good example of this:

There is only one line of music on this folio -- the ending of a chant that begins on the previous folio. Thus, we have no chant in CantusDB that has folio "A14r", but we do have a MEI file for folio "A14r" from the OMR process.

#892 introduced a way to handle these cases:

1. A user indexed the mei for a manuscript using the index_manuscript_mei command. When this command encounters MEI files for folios that don't exist, it does a preliminary sanity check (it ensures that the folio name "looks" like a folio name in that it has some numbers and maybe a trailing letter so that it wasn't just an accidentally copied file or some such) and then creates a folio in the CU database with that name. The command also alerts the user that it has done this.
2. The user must then manually map these newly created folios to image uri's in the IIIF manifest either through the django admin panel or the map folios process. The alerts from the command will be helpful in this regard.
3. The user must purge the index of omr_ngrams for that manuscript but running python manage.py index_manuscript_mei [manuscript_id] --flush-index.
4. The user must reindex the omr_ngrams for that manuscript. If the above has been completed, no warnings will appear.

This issue exists to simplify this process after changes to CU's indexing and data import process are made to more closely mirror CU's index with the contents of CantusDB