Store proxy password and apikeys in native OS credential store

[calixtus]

follow up to #9652
fixes #9652 (comment)
Fixes https://github.com/JabRef/jabref-issue-melting-pot/issues/106
depends on #10004

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.

[koppor]

On Windows 10, the Credential Manager displays it as follows:

Logitech uses / for separation:

Microsoft adds some key-value stuff, but I like the Logitech one better --> is it possible to replace the | with a /?

[calixtus]

No, the pipe char is hardcoded in the java-keyring library.

[calixtus]

https://github.com/javakeyring/java-keyring/blob/77358e960584109127835194320ca6061e9eac6f/java-keyring/src/main/java/com/github/javakeyring/internal/windows/WinCredentialStoreBackend.java#L59

[calixtus]

Some implementation changes were discussed:
The API keys should always be stored in the keyring an not in the preferences anymore at all.
The proxy config should directly include the option to persist the password instead of an abstract general option to use the key store.

[credmond]

Was this tested and confirmed using Ubuntu / GNOME? It doesn't work as Keyring.create() repeatedly returns null. I'd say this is OS specific, but do we understand where and when it won't work? When not possible, password saving probably shouldn't be provided as an option (as it's misleading behaviour). Current behaviour is to swallow exceptions, etc...