Extend/expand the involvment of trust in the (functional) tests

Currenlty functional tests like this one https://github.com/italia/eudi-wallet-it-python/blob/dev/example/satosa/integration_test/same_device_integration_test.py works in the following way:

1. a docker container with the configured satosa backend (RP-Verifier) must be up and running (we assume that it is this one https://github.com/italia/iam-proxy-italia ).
2. a python script simulates the interaction between the user device(s) and the RP, in particular it simulates:
2.1 the interaction between the service and satosa
2.2 the interaction of the Wallet-Holder with the pyeudiw module (RP-Verifier).
3. the PID Credential Issuer is not properly simulated in any way:
3.1 we assume that the wallet somehow got good credential like a valid sd-jwt (this is ok as going further is clearly of out scope from the RP viewpoint), and
3.2 we assume that the RP-Verifier magically has a copy of the PID Issuer public keys (as produced by the trust evaluation mechanism), which are inserted in the cache.

Point 3.2 is very brittle as the funcitonal tests basically never tests the working of the interactions between the RP and the credential Issuer, in particular; **current functional tests never verify the correctness of any trust evaluation mechanism that involves the PID credential issuer**.

IMO to have a full funcitonal test we should probably mock all external dependencies and not just assumme that the interaction with them magically worked in a previous interaction.
This is not very easy, but some issues like #341 and #340 (which were observed in testing with out partners) might be the result that there not enought tests with the trust module.