Network account fees

For full context, see the protocols tracking issue https://github.com/0xMiden/protocol/issues/3264 which will implement option C from https://github.com/0xMiden/protocol/discussions/2968#discussioncomment-17545587.

> [!NOTE]
> This is blocked until the protocol work is further along.

#### Approach Summary

The chosen approach is roughly as follows (finer details will depend on the protocol work).

1. Accounts providing some service will have a standard function which returns a fee estimate for a given user input note.
2. Users wishing to use this service will invoke this function to obtain a fee estimate.
3. Users submit their note, and an additional `SponsorshipNote` containing the fee for the service.
4. The sponsor note is linked to the user note directly, and can only be consumed if the user note is executed as well.
5. Service account consumes both, user note is executed, fee is claimed.

This applies to network accounts, and therefore network transactions need to support this flow.

### Wrinkles

- Sponsorship notes _do not_ have to originate from the same transaction as the user note.
- Some third party might sponsor the note, or
- user may post it some time later/earlier
- Multiple sponsorship notes may exist for a given note
- This also means multiple asset types can exist, though perhaps we can simplify initially so we don't need a price oracle.
- I imagine sponsorship notes can be reclaimable by the sender.
- Price fluctuations and decisions on when a sponsorship note is insufficient.
- Probably fair to just say one pass is good enough i.e. if it fails once then its dropped.
- Network account may itself depend on other third party services i.e. fee estimates can fan out.
- In general, fee estimations will require FPI.
- This also means users will invoke FPI much more regularly, and perhaps we should consider some dedicated caching here for network accounts in the node.