Brief datacite xml

[janvanmansum]

What this PR does / why we need it:
Add an option to generate datacite.xml with fewer datafile specific elements.

Which issue(s) this PR closes:

• Closes Suggestion: Limit the size of the datacite.xml generated by Dataverse for datasets with many datafiles (thousands) #12638

Special notes for your reviewer:

Suggestions on how to test this:
You can see the resulting datacite.xml by looking at the metadata export for DataCite. You may need to reexport first, to avoid seeing an older, cached version of the file. See: https://guides.dataverse.org/en/latest/admin/metadataexport.html#batch-exports-through-the-api

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

Is there a release notes update needed for this change?:
Yes, see: https://github.com/IQSS/dataverse/pull/12662/changes#diff-ea591f6967f307b36efb1e2ce30da90db2c09add68fb0283b84c96450ec5872a

Additional documentation:
None

[qqmyers]

@janvanmansum - I'm starting to review this and have an initial question - since this is a new global setting, is it useful for some reason to pass it down through the DataCite class hierarchy, and to have methods w/ and w/o the param at multiple levels? It seems to me like it would be simpler to just read the new param as part of constructing the XmlMetadataTemplate (or even statically since its a constant during any Payara run). I think the only real change in functionality is that this would assure that the param is used by the CrossRef and EZID DOI providers as well, which I think call XmlMetadataTemplate from the AbstractDOIProvider method, which is probably something we want. AI points out that this means that testing would have to be aware of the new parameter, but it isn't hard to make a test that reads a jvmparam (rather than having the XmlMetadataTemplate constructor that takes in the param value in the test now).