Implement the `#[sv::custom(msg=CustomMsg)]` attribute on the contract level

[hashedone]

• [x] #[sv::custom(msg=CustomMsg)] causes generated entry points returning the Result<Response<CustomMsg>, _>
• [x] Contract MT helper implements Contract<CustomMsg>
• [x] All MT helpers generated work properly with generic App (with specified ExecC)
• [x] #[messages(...: custom(msg))] on the contract implementation causes the conversion of responses dispatched on the interface

[hashedone]

Some notes about #[messages(..., custom(msg)] on trait implementation.

This attribute option is defined here to provide information for sylvia on which traits should be converted from Empty custom variants to proper custom variants and if it should be done for msg (right now the only one), or query. So finally in the future, it might be custom(query), or custom(msg, query).

The first thing to note here is that custom should never point to convert fields not listed in the #[sv::custom(...)], as those are Empty on the final contract and we don't want to execute conversion on it. For now let's make it a warning, with possibly upgrading into error in the future. The reasoning is that this kind of mistake would lead to a very nasty error compilation error compiling generated code, with zero hints of what actually got wrong in sylvia misusage.

Another thing is that I suppose that if one is using non-generic custom types for any customs in trait, he would be non-generic on all of them. It would lead to a case where in most cases one would always use #[messages(..., custom(msg, query)], and it looks like it's not necessary.

The solution is to make the whole arguments to custom here optional and allow for syntax #[messages(...: custom), which means "customize all the custom types listed in sv::custom for this contract".