Add instructions how to work with fetchers

[koppor]

This PR tries to summarize of how to work with fetchers locally.

I also added a fallback to environemnt variables in BuildInfo.java as I could not get it running locally.

My change in BuildInfo.java makes the handling more newcomer-friendly.

I am also opne to revert that change and to really desribe the IDE setup in the case of IntelliJ (and Eclipse) to enfore the reading of the "correct" build.properties even when running from the IDE (and not from gradle)

• Change in CHANGELOG.md described (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 documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[tobiasdiez]

Although environment variables are an improvement over the current situation, it would still restrict the people that can run the fetcher tests to the core team (since no one else has access to them). What about creating new dedicated keys for local development, which can be in the source code directly as fall-back options?

[tobiasdiez]

You can also run the processResources before a normal run with intellj (automatically in the run config). That works like a charm for me.

[koppor]

Similar issue for Eclipse or other IDEs. - When the keys are included in the source, we need to renew them to avoid hitting the API limit (you know, information leakage, ...)

With the the proposed PR, we are still in the situation, that only the core team can currently execute the fetcher tests. Alternatively the ones who are smart enough to read our build.gradle file and be able to use file search.

[koppor]

We try to have two different keys:

• production key (distributed)
• CI/CD key together with test key (included)

[koppor]

Requested changes implemented 😅