Enable support for non-indy ledgers

[ajile-in]

Is your feature request related to a problem? Please describe.

The Hyperledger.Aries.Agents.IAgentContext interface has a dependency on Indy SDK's WalletApi Hyperledger.Indy.WalletApi mainly due to Wallet & Pool classes. If we can extract out these dependencies into ledger-specific interfaces then it would become easier to start plugging-in more ledger-specific AgentContext for other ledger's e.g. HL Fabric, or Besu, etc.

Describe the solution you'd like

A rough idea of the proposed solution looks something like this:

1. Introduce an IWallet interface and extract Indy-specific interface methods into either IIndyWallet or IDefaultWallet interface as per an existing convention
2. Move PoolAwaitable Pool { get; set; } to this Indy-specific interface
3. Now a new wallet/ledger support can be added by introducing new ledger-specific interface e.g. IFabricWallet

public interface IAgentContext
{
        IWallet Wallet { get; set; }

        Dictionary<string, string> State { get; set; }

        IList<MessageType> SupportedMessages { get; set; }

        public bool UseMessageTypesHttps { get; set; }

        IAgent Agent { get; set; }
}

public interface IDefaultWallet : IWallet
{
        PoolAwaitable Pool { get; set; }
       // Other Indy-specific wallet methods go here ...
}

public sealed class IndyWallet : IDefaultWallet, IDisposable 
{
       // Indy-specific concrete wallet implementation goes here.
}

public sealed class FabricWallet : IFabricWallet, IDisposable 
{
       // e.g. Fabric-specific concrete wallet implementation goes here.
}

Similar changes may need to be introduced for Ledger specific implementation in order to support VDR API.

Additional context I am guessing that this may result into a breaking change in Indy SDK .NET Wrapper as well. Looking forward to more thoughts/suggestions on this approach.

[tmarkovski]

This is a good initiative, I think we can make this without breaking Indy SDK. I'd like the Indy dependency to be abstracted fully, so that we can have a bare Aries framework and able to add other signature schemes. The storage layer is currently very tightly connected to Indy, so this is the first part that needs to undergo this change. Just adding my thoughts here, glad to hear other are considering this, too.