Introduce `Payment`/`Invoice` struct

[Private note transport layer](https://github.com/0xMiden/miden-proposals/issues/4) is a very useful service for general-purpose notes. A good example would be viewing someone's **static** [`Address`](https://github.com/0xMiden/miden-base/issues/1454) online (think: double-anonymous donations) and sending them a payment, where potentially both the currency and the amount are not known upfront.

Paying for services usually involves the recipient fixing both the amount and the currency they wish to receive, and transmitting that information to the payer. We can simplify our use case so that the recipient receives a unique payment (i.e. the full payment details are non-reusable with other payers, even if the amount, currency etc. are the same - there must be some UUID involved). We would like to avoid using an external transport layer to share the notes between the payer and the receiver. Here is an idea:

1. The receiver shares a serialized `Payment` struct to the payer. This contains all the necessary information needed for both parties to generate the exact same `Note` details,
2. The receiver "saves" this note in their `Client` instance, so that the `Client` is going to track it whenever the note is committed onchain,
3. The payer creates a transaction issuing said `Note` _privately_,
4. The receiver's `Client` recognizes that a `Note` targeted for them was committed. They don't need to download its details, since the `Client` had already saved the note,
5. The receiver consumes the `Note`, crediting the account.

So 1. is fairly straightforward, we could have:
```rust
pub struct Payment {
account_id: AccountId,
currency: AccountId, // faucet's ID
amount: Felt,
serial_number: Word,
tag: NoteTag, // (maybe this is not needed, see further down)
}
```

We could achieve Step 2. by encoding a randomly generated* UUID into the `NoteTag`. This doesn't require changes on the protocol level, and for all intents and purposes should be efficient enough. Another option is for the `receiver` to somehow save the `Note`'s **commitment**, and watch for this commitment to appear onchain. ~~The trouble is that the commitment depends on `NoteMetadata`, which in turn depends on the sender's `AccountId` (which is authenticated in the kernel so we can't just insert a random sender), so watching for the commitment would require either 1) a full round of communication between the payer and the receiver, or 2) changing how the commitment is computed - but that might be not worth the trouble.~~

EDIT: I was confused by "commitment" vs. "id" for a `Note` (see [this issue to clarify](https://github.com/0xMiden/miden-base/issues/1731)).

Step 3. is already supported. If we put UUIDs into `NoteTag`, then step 4. amounts to the `Client` syncing state - already supported. Same for 5.

*randomly generated bits in `NoteTag`, rather than using `AccountId` make the recipient anonymous

So the tasks here are roughly:
- [ ] create the `Payment` struct
- [ ] decide on the naming, another option is `Invoice`
- [ ] implement `to_note_tag(&self) -> NoteTag;` on `Payment`
- [ ] propagate to miden-client