feat: publish trust metadata endpoint

[Zicchio]

This PR includes the following:

1. extends the TrustHandler interface to allow the possibility to publish trust-framework defined endpoints
2. introduce a new trust evaluation mechanism, called DirectTrustJar, that extends DirectTrustSdJwtVc, to let RP publish its own signing keys

Notably, it does NOT update the former federation publication mechanism to use this new endpoint. This is because this task is not-trivial and probably requires a dedicated pull request.
With the exception above, this closes #312 and closes #296. When merged, a new issue should be opened to update federation.

Due to restrictions introduced by which endpoint can be exposed by a satosa backend module, integration tests require this modification to work italia/iam-proxy-italia#177 . These two pull request are intended to be accepted side by side.

[peppelinux]

direct_trust_sd_jwt_vc should be kept ... at least as example!

[Zicchio]

@peppelinux with c0ced4a the commonalities between fetching / exposing a JWK with direct trust JAR and direct trust SD-JWT for VC have been grouped to a common (private) class called _DirectTrustJwkHandler (the name is whatever: I am open for suggestions).
In pratical terms, TrustJar and TrustSdJwt currently do nothing but provide sensible defaults for endpoint paths of _DirectTrustJwkHandler.

Currently, Both TrustJar and TrustSdJwt INHERIT from _DirectTrustJwkHandler but if desired we can migrate to a composition approach in the future (tranisition should be smooth): this would be especially desirable if jar and sd-jwt eventually require management of metadata other than key exposition, but currently this is not case so inheritance should be fine.