Multiple PID provider support

[qqmyers]

What this PR does / why we need it: Continues the refactoring of the PID Providers to now support

• instantiating multiple providers, of the same or different types (DataCite, EZId, Handle, Fake, PermaLink), with associated protocol, authority, shoulder, separator (for Perma)
• per provider lists of additional PIDs that are managed by or excluded from the set defined by the auth/separator/shoulder
• basic support for adding additional PidProvider types (classes not yet separated into the SPI)
• per collection setting of the PidProvider to use for new PIDs (datasets, or files created in an existing dataset when it is not possible to create additional PIDs with the dataset's protocol/authority/separator/shoulder)
• api calls to get provider info and see what provider a dataset will use to mint datafile pids, and superuser calls to set the dataset pid generator.

Which issue(s) this PR closes:

Closes #3623

Special notes for your reviewer: See explanatory doc.

I've gone ahead with a partial refactoring of the DataCite Provider, removing the old cache class, etc. There's still more that could be done, but I think that's better for future PRs.

I've also tweaked the installer to use the fake provider rather than putting in 10.5072 as an authority and default DataCite username/passwords and then swapping to use :DoiProvider=FAKE at a later step (i.e. for the Jenkins build). The docs are in synch and the installer text as well.

Suggestions on how to test this: The IT tests should handle legacy config and single provider cases. The unit tests check the basic logic of working with multiple providers. The main area to test would be in configuring multiple providers via microprofile and testing relevant scenarios, e.g. using a test DataCite provider and a PermaLink provider, etc.

There's also a semi-automated test of the DataCite provider. See the DataCiteProviderTest class - you basically have to export username/password/authority/shoulder for a valid DataCite test account and then run the test - it will go though creating, updating, publishing, deaccessioning the DOI at DataCite (leaving one non-deletable DOI in the 'register' state in your account).

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?: yes

Additional documentation: included

[qqmyers]

@stevenwinship - try that. The basic issue is that Dataverse will refuse to launch if a valid pid provider isn't set up using the new microprofile/jvm options. I've added those to the docker/composer.yml file, which I hope is what's used for the docker launch. If so, hopefully this clears your error. If not, we'll need to find the right place to add these settings.

[pdurbin]

There's also docker-compose-dev.yml in the root of the repo. Pick your poison. 😄

[qqmyers]

OK - I've added there too - thanks.

[qqmyers]

Sorry for the typos!

[stevenwinship]

Stack trace when logged in as admin and create dataset. This is out-of-the-box with no other configurations running in docker:

stacktrace.txt

Adding -Ddataverse.pid.default-provider=fake fixes this issue

[stevenwinship]

QA testing completed. Once the -Ddataverse.pid.default-provider=fake is added this PR is good to merge