Adjust JATS generation handling

[asmecher]

Now that #7505 is implemented, JATS generation is no longer purely a plugin consideration -- the core application relies on the JATS Template plugin in order to generate a basic JATS document when none is upgraded.

It's a good opportunity to re-evaluate the division of effort between the application, JATS Template plugin, and OAI JATS plugin.

Proposals:

• Consider moving the code that overlays OJS metadata over a possible existing JATS document into the JATS Template plugin, instead of the OAI JATS plugin.
• If that is possible, then it should be easy to distribute the OAI JATS plugin as part of OJS, without expecting users to need to update it between releases. This will decrease the number of plugin updates required for Coalition Publica journals.
• Continue to generate the vast majority of JATS content in a plugin. This will ensure that JATS generation can easily be iterated outside of the OJS release cycle, which is likely to continue to be necessary.
• Clean up and make logical the methods by which the core can interact with the JATS template plugin.
• Ship a copy of the JATS Template plugin with OJS, but expect to release updates out-of-band.
• Since we will potentially have multiple sources for JATS, examine the relationship between sources. For example, #10432 adds support for funding data (from the funding plugin) to the JATS template; should this be implemented in the JATS Template plugin? Or the funding plugin? If in JATS Template, how do we minimize the effects of data model changes in the funding plugin?

See also:

• Add option to present JATS with galleys #10436

[asmecher]

I've added the JATS Template and OAI Jats plugins as submodules for OJS for release in 3.5.0. @jalperin has committed to reviewing the JATS implementation to check whether the JATS implementation exposes anything that shouldn't be exposed by default; depending on the outcome of that we can consider whether the plugins should be made enabled on install or not.