Make a distinction between PresentationManager's and TransferManager's ReaderTrustStores

[breynders-cb]

Currently, the trust store in EudiWalletImpl is set through setTrustedReaderCertificates which in turn executes the following:

eudi-lib-android-wallet-core/wallet-core/src/main/java/eu/europa/ec/eudi/wallet/EudiWalletImpl.kt

Lines 62 to 64 in 8493cfb

	(this as PresentationManager).readerTrustStore = readerTrustStore
	if (transferManager is ReaderTrustStoreAware) {
	transferManager.readerTrustStore = readerTrustStore

It creates the same trust store for both the presentation manager and the transfer manager. This causes issues for the (remote) OpenID4VP flows that aren't subjected to the (I suppose stricter?) requirements for MSO MDoc's reader certificates. For example, right now an x509_hash based verifier has to pass these rules:
https://github.com/eu-digital-identity-wallet/eudi-lib-android-iso18013-data-transfer/blob/d36293a599ce12dc73e72242b5ac49a9cbe03d3e/transfer-manager/src/main/java/eu/europa/ec/eudi/iso18013/transfer/readerauth/profile/ProfileValidation.kt#L25-L34

In short, requiring:

• authority key
• subject key
• common name
• not allowing certain critical extensions: (Extension.policyMappings.id, Extension.nameConstraints.id, Extension.policyConstraints.id, Extension.inhibitAnyPolicy.id, Extension.freshestCRL.id)
• key usage digital signature
• signature algorithm has to be ECDSA_with_SHA[256, 384, 512]

which is all fine (but can be documented better to make it easier for verifiers to generate a valid certificate).

However, it also has more obscure requirements:

• max validity period <= 1187 days
• extended key usage needs to be mdlReaderAuth oid: 1.0.18013.5.1.6.

I believe this is also the root cause of another open issue: #230,

[sraptis-scy]

This is acknowledged and added to our roadmap, the core will differentiate configuring the ReaderTrustStore for Remote VP and Proximity verifications.