Mappings for Aeon OpenURL-based requests

[anarchivist]

Acceptance criteria

Given a repository with a configured Aeon instance, provide the ability to define mappings for that repository for OpenURL parameters from information in an ArcLight collection/component or some other method (e.g. a function that generates values). The mappings should be configurable per repository, as they may vary across each.

• [x] Create list of fields (see #647 as an example)
  • decision: We won't provide a comprehensive list of fields or validate them; this would be on Aeon implementers:
• [ ] Implement mapping configuration along something like the following, supporting both accessors and static values:
• [ ] For multivalued fields, join values with "; " and return a string

mockup

```yaml aeon_openurl: aeon_web_url: https://example.com/aeon/aeon.dll open_url_mapping: rft.title: title # this is an accessor rft.au: creator # this is an accessor rft.genre: "manuscript" # this is a static value ```

[escowles]

The Atlas docs for OpenURL field mapping are here: https://support.atlas-sys.com/hc/en-us/articles/360011919573-Submitting-Requests-via-OpenURL

Because this is configurable, it's hard to say what's required here — just that what's configured in ArcLight should match what's configured in Aeon.

[anarchivist]

@escowles Would a key/value pair work for a mapping, where the key could be a OpenURL context object's parameters? The value could either be a static value or use one of the accessors described in #644.

[escowles]

@anarchivist Yes, that sounds workable: being able to configure a set of key-value pairs, where the key was the OepnURL parameter name, and the value was either a static value or one of those accessors.