Upgrade EndNote XML exporter to StAX

[subhramit]

Follow-up to #11157

Upgrade EndNote XML exporter

Refs. #11157 (comment)

• Upgrades existing EndNote XML exporter to StAX for better memory efficiency.
• Removes transformer to improve memory efficiency further (like Zotero).

Note: In the existing lambdas, now XMLStreamException is caught and thrown as RuntimeException as lambdas don't allow checked exceptions to be directly thrown from them.

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[calixtus]

About RuntimeException: ModsExporter also uses StAX and works with the so called SaveException. Does this maybe help?

[subhramit]

About RuntimeException: ModsExporter also uses StAX and works with the so called SaveException. Does this maybe help?

It did, took some inspiration. Used SaveException to handle the file export (the class mostly handles files unavailable for writing due to locking by another process).
Also added more precise exceptions to lambdas.

[subhramit]

Another prominent change - removed the transformer.
Tradeoff - can't pretty-print the XML anymore.
Benefit - even more memory efficient (for large databases) as we directly write to the output stream instead of building the unformatted xml in memory and then transforming it.
Zotero does it this way too.

[koppor]

Tradeoff - can't pretty-print the XML anymore.

Why? StackOverflow says different:

• https://stackoverflow.com/a/3625359/873282
• https://stackoverflow.com/a/485126/873282
• https://stackoverflow.com/a/2368681/873282

Benefit - even more memory efficient (for large databases) as we directly write to the output stream instead of building the unformatted xml in memory and then transforming it. Zotero does it this way too.

[koppor]

@Siedlerchr I find the new code less maintainable than the old one. In both codes, we do NOT need to generate Java-classes based on some XSD file. -- I propose to use this PR as learning for Subhramit for StAX, but close the PR due to maintenance concerns (see for example the necessary comment on closing XML elements).

[Siedlerchr]

Yes that seems to be odd

[koppor]

DevCall: Longer discussion. We close. However, in case someone shows up with a large library and gets out of memory exceptions, we will reconsider.