feat(dan): template macro handles component state

[mrnaveira]

Description

• Function parameters are correctly encoded and passed to the user function
• Component parameters (i.e. self) are transparently handled to the user code:
  1. The ABI specifies a u32 type component id
  2. The state is retrieved from the engine with that component id (not the real call yet, as it's not implemented in the engine)
  3. The state is decoded and passed to the function on the self parameter
  4. If the attribute is mutable (&mut self) then we call the engine to update the component state
• Unit return types (()) are now supported in functions (see the State.set function as an example)
• Expanded the ast.rs module with convenient functions to detect self and constructor functions

Motivation and Context

Following the previous work on the template macro (#4358, #4361), this PR aims to solve some of the previous limitations:

• The function arguments must be processed and encoded
• Struct fields and self must be handled
• Calls to the tari engine import should be done instead of mocked

With those implemented, the state test example is now written as:

use tari_template_macros::template;

#[template]
mod state_template {
    pub struct State {
        pub value: u32,
    }

    impl State {
        pub fn new() -> Self {
            Self { value: 0 }
        }

        pub fn set(&mut self, value: u32) {
            self.value = value;
        }

        pub fn get(&self) -> u32 {
            self.value
        }
    }
}

Please keep in mind that this is the simplest example that manages the contract state, but it currently supports function logic as complex as the user wants, as long as it is valid Rust code.

Also, for now I didn't find necessary to mark constructor functions in any special way. Right now, a function is automatically considered a constructor (and the component instantiated) if it returns Self.

Lastly, as the state managing itself is not yet implemented on the engine, state is not conserved between calls. But this PR encapsulates component related logic in a single module (component.rs) so it should be relatively simple to implement in the future.

How Has This Been Tested?

The unit test for the state example, now rewritten using the template macro, pass

[stringhandler]

Nice