Introduce a burn address for cdk_erigon

[LindaGuiga]

This PR closes #92.

This PR introduce a burn address BurnAddr when the cdk_erigon feature is activated. The BurnAddr receives the burnt fees when the feature is activated. This is achieved similarly to the fee payment for the sender: first, we add the maximum fee to the burn address, then we deduct the fee corresponding to the remaining gas.

For now, the default value (0x0) is set in the trace decoder.

[Nashtare]

@LindaGuiga If you merge latest develop the clippy errors will go away.

[Nashtare]

I'm mostly good with it, but left some comments to discuss / address.

[Nashtare]

I'm good with this once rebased + revert the changes linked to macro -> global label post #492

[0xaatif]

I don't want to feature-gate fields in a public struct.

I support features when they add to the public API in ways that don't require code changes from users.

This is fine

pub fn foo(p: &str) {
    #[cfg(feature = "str")] // implementation detail
    ...
}

This is not

#[cfg(feature ="str")]
pub fn foo(p: &str);
#[cfg(feature ="bytes")]
pub fn foo(p: &[u8]);

As you've added it, the feature is viral - now trace_decoder needs conditional compilation too, but I don't think it should.

Can you think of a way of phrasing the public API such that it doesn't need conditional compilation? Perhaps an enum that's always present?

[Nashtare]

I'm broadly good with this, mostly light comments. @0xaatif could you tell us if you're satisfied with how the decoder looks now, following your latest discussions with Linda.

[0xaatif]

The TODOs are a blocker, and the inversion of control is a strong suggestion.

defer

[Nashtare]

@0xaatif will you review the latest changes following resolved discussions or defer to other code owners? (what your latest comment seems to imply)
Just to clarify so that @LindaGuiga knows what to do once last comments are addressed