feat: add macros for shared interfaces

[milapsheth]

AXE-6852

Shared interfaces can now be implemented via derive macros:

use axelar_soroban_std::{Operatable, Ownable, Upgradable};

#[contract]
#[derive(Operatable, Ownable, Upgradable)]
pub struct AxelarGateway;

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.58209% with 22 lines in your changes missing coverage. Please review.

Project coverage is 95.26%. Comparing base (bdf9443) to head (912e8dc).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/axelar-soroban-std-derive/src/lib.rs	84.42%	19 Missing ⚠️
contracts/axelar-gas-service/src/contract.rs	0.00%	1 Missing ⚠️
contracts/interchain-token-service/src/contract.rs	0.00%	1 Missing ⚠️
contracts/interchain-token/src/contract.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
+ Coverage   93.74%   95.26%   +1.52%     
==========================================
  Files          47       48       +1     
  Lines        3053     3083      +30     
==========================================
+ Hits         2862     2937      +75     
+ Misses        191      146      -45     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cgorenflo]

I do like the approach, but a few notes:

• I'd prefer if contracts don't have to depend directly on the derive crate, instead have an indirect import (potentially with feature flag "derive") in the axelar-soroban-sdk. See the amplifier repo for how to do that
• remove the leading :: in paths, it makes the code much more brittle, like with goldie, and you have to define the import at the root level, it won't look at the local relative context
• you only showed the trivial migration data example, how does it work with more complex data?
• Are you sure that the contract proc macro actually picks up on the generated code and creates entrypoints for it?

[milapsheth]

remove the leading :: in paths, it makes the code much more brittle, like with goldie, and you have to define the import at the root level, it won't look at the local relative context

The Rust doc recommended the :: prefix to avoid collisions, but your point regarding goldie is valid, and collisions are unlikely in this case

[milapsheth]

I'd prefer if contracts don't have to depend directly on the derive crate, instead have an indirect import (potentially with feature flag "derive") in the axelar-soroban-sdk. See the amplifier repo for how to do that

Yeah, forgot about that. Refactored