Specify optional dependencies per feature

[lukpueh]

We use optional dependencies (aka. extras) to allow a default installation with limited capabilities (e.g. verify ed25519 signatures using a pure Python implementation), which is useful for securesystemslib dependents (e.g. python-tuf), that need to be installable without any native dependencies (e.g. vendored into pip).

The full or a specific larger feature-set (e.g. signing) can be installed by specifying those extras like so:

pip install securesystemslib[crypto, asn1, pykcs11] # for hsm signing support

Except for hiding version constraints this is hardly more useful than telling user to install like so

pip install cryptography asn1crypto PyKCS11

Current behavior:

Specified per library:

securesystemslib/pyproject.toml

Lines 45 to 51 in e2a08b1

	[project.optional-dependencies]
	crypto = ["cryptography>=37.0.0"]
	gcpkms = ["google-cloud-kms"]
	pynacl = ["pynacl>1.2.0"]
	PySPX = ["PySPX==0.5.0"]
	asn1 = ["asn1crypto"]
	pykcs11 = ["PyKCS11"]

Expected behavior:

• figure out what "features(s)" cryptography, pynacl should be mapped to (or leave those as they are)
• specify per feature,

[project.optional-dependencies]
[...]
gcpkms = ["google-cloud-kms"]
pq = ["PySPX==0.5.0"]
hsm = ["asn1crypto", "PyKCS11", "cryptography"]

Caveat:
Specifying them per feature is prone to redundancy. E.g. cryptography is needed for an hsm signing, but also for a traditional securesystemslib signing and gpg singing.

[jku]

I suppose the real "features" look roughly like this:

feature: dependency
ed25519 (sign): pynacl
ECDSA: cryptography
RSA: cryptography
SPHINCS: PySPX
GCP: google-cloud-kms, cryptography
HSM: asn1crypto, PyKCS11, cryptography

The first four are just scheme-support that forces a certain version: whether we name the feature by the scheme-family or the dependency itself is not very important I think? Maybe we just leave them as they are (so the feature name is the dependency name) so we don't annoy existing users?

Last two (and hopefully more future features) are more interesting and should be named by the feature: I guess the acronyms are good enough? I don't see any major issue with the redundancy

Maybe GPG feature should also be defined -- it does depend on cryptography at least -- but I can see why that would be misleading as well... So maybe let's not tackle that issue here.