Refactor Sandbox

[pgherveou]

This PR does the following refactoring, to prepare further update that will make it easier to integrate Drink with a Network of chains connected through XCM:

Specifically it does the following:

• Use generics instead of hard coded types, so we can adapt e2e tests to various runtimes
• Refactor Sandbox so that it can be used with runtime that do not implement contracts (such as a Relay chain Runtime for example)

For example token APIs only require the Sandbox to be generic over something that implement pallet_contracts

impl<R: pallet_balances::Config> Sandbox<R> {
    /// Add tokens to an account.
    ///
    /// # Arguments
    ///
    /// * `address` - The address of the account to add tokens to.
    /// * `amount` - The number of tokens to add.
    pub fn add_tokens(
        &mut self,
        address: AccountIdFor<R>,
        amount: BalanceOf<R>,
    ) -> Result<BalanceOf<R>, DispatchError> {
        self.execute_with(|| pallet_balances::Pallet::<R>::mint_into(&address, amount))
    }

    /// Add tokens to an account.
    ///
    /// # Arguments
    ///
    /// * `address` - The address of the account to add tokens to.
    /// * `amount` - The number of tokens to add.
    pub fn balance(&mut self, address: &AccountIdFor<R>) -> BalanceOf<R> {
        self.execute_with(|| pallet_balances::Pallet::<R>::free_balance(address))
    }
}

[pgherveou]

I love the direction of this changes, that would finally allow to work freely with any runtime, not only for contract purposes, but for general interaction as well

if I understand the intention correctly, the idea is that:

* `Sandbox` essentially wraps externalities and has a generic argument for a runtime, which can be actually anyhow configured

* depending on this generic argument, `Sandbox` enables pallet-specific operations, but not through traits (`like ChainApi` and `ContractApi`), but rather through generic bounds

is that so?

Yes. That's pretty much what Sandbox was doing already (as far as I understand). I just moved the constraints around to make it more flexible and work with any Runtime as long as they implement the right config. We could re-introduce the traits and implement them for runtime that implement the right configs but I don't think it's necessary, simple generics bounds implementation should be enough here.

[pgherveou]

Addressed your comments

[pgherveou]

@deuszx @pmikolajczyk41 not sure what kind of approval is required to trigger CI here, you mind re-approving so we can merge this asap?