Generic contract alias produced by #[contract] or #[entry_points] macro

[kulikthebird]

Let's consider macro-generated types aliases for a contract's strucutre along with ContractExecMsg, ConractSudoMsg, ContractQueryMsg and InstantiateMsg. This might be useful when the contract structure is generic. Eventhough it's generic, the entrypoints must use only a single monomorphisation of that structure e.g.:

struct Contract<GenericT1, GenericT2> {
    gen_types: std::marker::PhantomData<GenericT1, GenericT2>
}

#[sylvia::entry_points(generics<SomeCustomMsg, SomeCustomMsg>)]
#[contract]
impl<GenericT1: CustomMsg, GenericT2: CustomMsg> Contract<GenericT1, GenericT2> {
    // [...]
}

#[contract] or #[entry_points(generics<SomeCustomMsg, SomeCustomMsg>)] could introduce the following type aliases:

// macro-generated module
mod sv {
    type SvContractTypeAlias = Contract<SomeCustomMsg, SomeCustomMsg>;
    type SvContractExecMsgTypeAlias = ContractExecMsg<SomeCustomMsg, SomeCustomMsg>;
    type SvContractQueryMsgTypeAlias = ContractQueryMsg<SomeCustomMsg, SomeCustomMsg>;
    type SvContractSudoMsgTypeAlias = ContractSudoMsg<SomeCustomMsg, SomeCustomMsg>;
    type SvInstantiateMsg = InstantiateMsg<SomeCustomMsg>;
    // [...]
}

Those aliases could be used in at least two contexts:

• CodeId<Contract> requires specifying the contract type. It might be useful to use aliases instead of adding the generic types each time the tests
• write_api! macro requires to specify ContractExecMsg, ContractQueryMsg and ContractSudoMsg structures with all the generics that were specified in the entry_points macro. That can be automated and protect contract devs from specyfying different generic types by mistake.

On top of that a new macro sv_write_api! could be implemented to remove the boilerplate code in schema generating code:

fn main() {
    sv_write_api! {
        path::to::contract_module,
        instantiate,
        execute,
        query,
        sudo,
    }
}

[jawoznia]

On the one hand this is directly connected to the types used by the contracts entry points so it could be defined inside entry_points macro.
On the other it would be great to expose those types as they most likely will be tested by the user and all the multitest helpers are generated by the contract macro.

I think we could move the generics to some attribute (I don't see a good name for it at the moment) and then use it in the contract and entry_points.

In such case entry_points macro should emit_error in case the contract is generic and attribute is not present.