refactor: Deduplicate dependency versions

[Hocuri]

Deduplicate dependency versions by specifying them only once in Cargo.toml for the whole workspace under [workspace.dependencies].

Where possible, also deduplicate the dependencies' features (if different crates use different set of features, of course these can't be deduplicated).

[iequidoo]

Where possible, also deduplicate the dependencies' features (if different crates use different set of features, of course these can't be deduplicated).

They are actually deduplicated this way (https://doc.rust-lang.org/cargo/reference/resolver.html#features):

When building multiple packages in a workspace (such as with --workspace or multiple -p flags), the features of the dependencies of all of those packages are unified. If you have a circumstance where you want to avoid that unification for different workspace members, you will need to build them via separate cargo invocations.

So, each dependency is built only once with all requested features. Not a problem if we don't have any dependencies with mutually exclusive features.

EDIT: But i think it's better to use Feature resolver version 2.
EDIT: We have edition = "2021" in Cargo.toml, so we're already using the Feature resolver v2 actually.

[Hocuri]

They are actually deduplicated this way (https://doc.rust-lang.org/cargo/reference/resolver.html#features):

I know, what I meant is: deltachat-ffi needs yerpc only with features ["anyhow_expose"]. deltachat-jsonrpc needs it with ["anyhow_expose", "openrpc"]. So, I didn't put any of the features into [workspace.dependencies].

This is purely a choice what we like better; I could as well have put the anyhow_expose into [workspace.dependencies], since all crates that use yerpc enable this feature. Or I could have put no feature flags at all into [workspace.dependencies], not deduplicating them. I chose the described middle ground.

If you have a circumstance where you want to avoid that unification for different workspace members, you will need to build them via separate cargo invocations.

That's what we do in this case, we use one cargo invocation to build deltachat-ffi and another one to build deltachat-jsonrpc. This is not changed by this PR.

---

Not sure I explained everything in an understandable way, but also, it's not that important, I think it's fine to ignore that I ever mentioned features :)

[iequidoo]

I chose the described middle ground.

I'd prefer not to deduplicate any features at all, otherwise if a new package not requiring the given feature appears, you should "duplicate the features back". Or deduplicate a feature only if there are some strong reasons to use it in all packages. I think this way it's just easier to maintain dependencies' features.

[iequidoo]

Wrt the dependencies' features, it doesn't look critical anyway, but i'd wait for @link2xt's approval before merging