feat: adding note args and tests

[Dominik1999]

Closes #338

Supersedes #374

Still unsure how we want a user to set note_args. Atm a user need to define note_args when creating the InputNote

[bobbinth]

Thank you! Looks good! I left a could of comment inline - the main one is about how we provide note args to the transaction executor.

Also, the MASM code will need to be updated a bit once this PR is rebased from the latest next.

[bobbinth]

Thank you! Looks good. I left some comments inline. The main thing is that I think we can simplify the structure quite a bit by following a similar pattern as for note inputs. Specifically:

1. In the prologue (i.e., in the process_input_notes_data procedure), we can get note args from the advice provider and put them next to other note data.
2. Then, right before the note is executed (e.g., as a part of prepare_note procedure), we would put note args onto the stack.

This way, when a note scripts starts executing, the state of the stack would be:

[SCRIPT_ROOT, NOTE_ARGS, ...]

[bobbinth]

Thank you! Looks good! I left a some more comments inline. Most are pretty minor. The main one is about figuring out the right place to add note args into the process.

[bobbinth]

Thank you! I think this approach works better. I left some more comments inline.

[bobbinth]

I think this was supposed be be:

pub struct TransactionArgs {
    tx_script: Option<TransactionScript>,
    note_args: BTreeMap<NoteId, Word>,
}

[Dominik1999]

Not sure if I follow. NoteArgs are optional to a transaction the same way as a TransactionScript, right? So the canonical way to indicate this optionality would be

pub struct TransactionArgs {
    tx_script: Option<TransactionScript>,
    note_args: Option<BTreeMap<NoteId, Word>>,
}

Why would you put note_args: BTreeMap<NoteId, Word> not as an option?

[bobbinth]

An empty BTreeMap is functionally equivalent to None in this case but without the extra step we need to take to unwrap it.