Create cw-orch wrapper for simple test scenario

[ismellike]

We have a lot of replicated code for setting up a simple deployment flow across our tests: [staking] -> ... -> token weighting

We can make use of a cw-orch wrapper to make this setup way more simple.

#84 has some good examples and setup for a full deployment already (excluding splitter). Maybe we can just use those to some extent?

[ismellike]

Here's a good example wrapper: https://github.com/Lay3rLabs/commitments/blob/cli-deploy-improvements/deploy/src/deployments/staking_provider.rs

It takes in some context StakingProviderData to be used in the deploy_on function to specify how the contracts will be uploaded and configured. We should brainstorm what information we want to pass into the wrapper to create the test-case flow.

[ismellike]

These changes should be based off code in #111 which uses #84

Update: above is now merged into main

[gangov]

We should brainstorm what information we want to pass into the wrapper to create the test-case flow.

for each contract in restaking (delegations, fan-in, fan-out, operators, splitter, token-staking, token-weighting), figure out all the initialization parameters and configs that they need.

we need DeployData struct that encapsulates the configuration data for the test case. This struct should include:

* Tokens: info about existing/new tokens (name, symbol, initial balance).
* Providers and Consumers: Their configurations, security levels, associated tokens.
* Operators: Addresses and permissions.
* Relationships: connections between contracts (e.g., fan-in, fan-out, splitter) and any specific parameters like share percentages.
* Security Levels: Unbonding periods, maximum penalty percentages.

Example:

struct RestakingTestCaseData {
    tokens: Vec<TokenConfig>,
    providers: Vec<ProviderConfig>,
    consumers: Vec<ConsumerConfig>,
    operators: Vec<OperatorConfig>,
    relationships: Vec<ContractRelationship>,
    // ... other necessary fields
}

note: if the vec is empty then we don't need the specific contract and we skip it in the setup

implement the Deploy Trait Using the RestakingTestCaseData

impl<Chain: CwEnv> cw_orch::Deploy<Chain> for RestakingContracts<Chain> {
    type DeployData = RestakingTestCaseData;
    // ... implement store_on, deploy_on, etc..
}

helper methods within the wrapper struct - eg. implement methods that handle the deployment logic using the provided data like deploy_token, deploy_provider, deploy_consumer, setup_relationship, and add_operator.

use the wrapper in test cases (common.rs?) by providing a RestakingTestCaseData instance that simulates the desired scenario.

[ismellike]

struct RestakingTestCaseData {
    tokens: Vec<TokenConfig>,
    providers: Vec<ProviderConfig>,
    consumers: Vec<ConsumerConfig>,
    operators: Vec<OperatorConfig>,
    relationships: Vec<ContractRelationship>,
    // ... other necessary fields
}

note: if the vec is empty then we don't need the specific contract and we skip it in the setup

Hmm I think we should preserve the graph-based instantiation. This could work, but it might become difficult to work with going forward.

Our current staking_provider.rs is good and should be moved to the commitments-interface. It can easily configure the provider side for multiple tokens with StakingProviderData.

#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct StakingProviderData {
    pub token: TokenConfig,
    pub unbonding_period: u64,
    pub slash: u16,
}

#[derive(Serialize, Deserialize, Debug, Clone)]
pub enum TokenConfig {
    Existing {
        denom: String,
    },
    New {
        name: String,
        symbol: String,
        initial_balance: u128,
    },
}

What I don't like about the avs_consumer.rs is that it doesn't have an optional delegations or operators contract. I think the fan_in and weighting should be required though.
It would make sense to create another consumer.rs where we take the existing code and make it more flexible. Then, the avs_consumer can just be a specific implementation of consumer.rs (always pass in Some(DelegationsConfig) and Some(OperatorsConfig)).

Once that's defined, we can create a simple wrapper over these simple_flow.rs that will take in StakingProviderData and ConsumersData (Vec<ConsumerData> and defineFlows() config).

We should also consider how to define a Splitter somewhere in this flow.