Refactor publish-options in user settings to support multiple endpoints

[hmaier-fws]

Issue Description:

Refactor how the user specified "Publishing Settings" are stored in the "type": "settings" object. The settings are currently stored as a single object, but should be stored as an ARRAY of objects.

Currently, the "Publishing Settings" is only configured for ScienceBase. However, it is possible that other publishing end points may be added in the future. To support potential extension, and to provide consistency with how other settings are stored (e.g., "Metadata Repositories", "custom-schemas"), the publishing-options should be refactored as an array, that could support several objects.

This would also allow for the possibility of each publishing endpoint to specify any number of settings.

Current structure:

"repository-defaults": [
    {"repository": "data.gov", "title": "repo data.gov"},
    {"repository": "ScienceBase", "title": "repo Science Base"}
],
"publish-options": {
    "sb-publishEndpoint": "https://sbmd-service.djcase.com/", "sb-defaultParent": "12345"
},
"custom-schemas": []

Updated structure:

"repository-defaults": [
    {"repository": "data.gov", "title": "repo data.gov"},
    {"repository": "ScienceBase", "title": "repo Science Base"}
],
"publish-options": [
    {"sb-publishEndpoint": "https://sbmd-service.djcase.com/", "sb-defaultParent": "12345"},
    {"some other publisher": "https://pub.org", "pub-optionA": "option-1", "pub-optionB": "option-2"},
    {etc...}
"custom-schemas": []

[hmaier-fws]

@eyeyellow I wonder if we want to include a key to identify the publisher, similar to how the repository-defaults are configured. E.g.:

"publish-options": [
  {
    "publisher": "ScienceBase",
    "publishEndpoint": "https://sbmd-service.djcase.com/",
    "sb-defaultParent": "12345"
  },
  {
    "publisher": "some other publisher",
    "publishEndpoint": "https://pub.org",
    "pub-optionA": "option-1",
    "pub-optionB": "option-2"
  }
]

With the publisher and publishEndPoint being common to all publishers and any other values left up to the discretion of the potential publishers.

[eyeyellow]

@hmaier-fws Yes, that makes sense to me. Then that publisher key can be used as an identifier for that item in the array.

When displaying the list of different publishers, this key can also act as a label. Or we can add another field for that.

In any case, using a key as the identifier will be necessary with this array approach.

[hmaier-fws]

@eyeyellow I'm not opposed to adding a separate keys for referencing the object and for use in display. I guess I was thinking that the "publisher" would serve both purposes. We can go with whatever you think is best.

But, after thinking about this, I'm wondering if we want to include an optional "description" property. That might be useful if we have several publishers listed. That would allow the publisher to provide additional information if they desired to do so. Something like:

@adiwg/fws-stakeholders do you think adding an optional description to the "settings / publisher display" would be a useful enhancement?

[hmaier-fws]

This issue proposes that the new structure of the publisher settings use:

{
  "publisher": "key to identify publisher (string)",
  "publishEndpoint": "url to publisher endpoint (string)",
  "publisherSpecificOptionA": "optionA",
  ...
}

The initial discussion leaned toward having publisher and publishEndpoint as common elements for all publishers, followed by any publisher specific options. When looking at #764 I noticed that the existing ScienceBase user settings use sb-publishEndpoint and sb-defaultParent.

@dvonanderson from your perspective, is there any advantage to requiring the use of both publisher and publishEndpoint? Or should we just simplify and keep publisher as the only required key for the publishing options?

I can't think of a need for both. But this also has me thinking that when a publishing add-on is created, we should also document what that publisher expects to see in the user settings.