Revert deprecation

[koppor]

Following the discussion at #1913, that PR should be reverted.

This PR reverts the @Deprecations, but tries to keep the other improvements.

I'm not sure whether BibEntry.getResolvedField should be kept.

[tobiasdiez]

The insertEntryWithDuplicationCheck vs insertEntry can be reverted. That was my bad not to recognize that "checkDuplicaiton" also changes the bibtex key (we should rename the method!).

As for reverting the other changes, I put my veto in. Moving getResolvedField to the entry was just a refactoring without any negative side-effects (that I'm aware of). And I already commented why the static fields in BibEntry should be private: they are implementation details!

[Siedlerchr]

As I noted in the other issue, the problem with the static fields is that
they are used in fetchers and importers/exporters to just check if the
actual encountered field is the key or not. You can not simply set them to
private without having a solution for the things.

[tobiasdiez]

Yes I know, if I would have an easy solution for this case, then I already could have implemented it and there would be no need to mark it as deprecated. Again, deprecated does not mean that it is forbidden to be used and that we have to remove it immediately but it signals "hey deer (sic!) developer, please think twice about using this method. We try to remove it but right now are not able to. Please don't make it harder for us by adding yet another use case. But go ahead if there is no other solution.".
I think this is exactly what we need for the citekey / id.

[koppor]

OK, guys. Regarding some comments at #1913 (comment), I currently cannot really judge what's the best way. I had some personal discussions and thus, I merge this in and we should discuss in the devcall how to proceed.