Multidocument config options

[ajolipa]

In this PR

Adds the option to configure the EditionCrafter component to accept multiple documents, by setting the variorum prop to true and passing in an object with document IDs as keys as the documentInfo object.

For example, a variorum configuration could look like

<EditionCrafter config={{
    documentName: 'FHL_007548733_TAOS_BAPTISMS_BATCH_2 and eng-415-145a',
    variorum: true,
    documentInfo: {
      FHL_007548733_TAOS_BAPTISMS_BATCH_2: {
        documentName: 'Taos Baptisms Batch 2',
        transcriptionTypes: {
          translation: 'Translation',
          transcription: 'Transcription',
        },
        iiifManifest: 'https://cu-mkp.github.io/editioncrafter/taos-baptisms-example/iiif/manifest.json',
      },
      eng_415_145a: {
        documentName: 'Eng 415-145a',
        transcriptionTypes: {
          'eng-415-145a': 'Transcription',
        },
        iiifManifest: 'https://cu-mkp.github.io/bic-editioncrafter-data/eng-415-145a/iiif/manifest.json',
      },
    },
  }}
  />

This results in the following behavior, including the ability to unlock the two panes from each other and view a folio from one document on one side and another document on the other side:

Notes and future work

• There is not a lot of flexibility or intelligent error handling built into the component props at the moment; if you use the wrong key for something, or forget to set variorum to true, etc., the viewer will crash.
• More work needs to be done on allowing you to truly decouple the behavior of the two sides; currently even if you are in unlocked mode, going to a new folio on the left side will reset the righthand side to show the text of that folio. Possibly when using the viewer for comparing multiple documents that behavior is not desirable and it should be possible to just operate within each pane of the viewer independently more easily.
• Currently I completely punted on dealing with the glossary; if variorum is set to true, then an empty glossary is returned. Presumably each document could come with its own glossary link, so instead of loading the glossary when initializing the grid view, I suppose it should be loaded from the proper manifest once a specific folio is chosen? But implementing that will take another chunk of work.

[NickLaiacona]

Hi @ajolipa , two things on this PR. First, can you move the code into a branch in this repo instead of a fork in your own repo? Second, the PR merge target should be either the develop branch or a develop branch just for ely-green related features. Thanks!