feat!: batch note validation check

[nventuro]

This massively improves performance of the note discovery process by enabling batching of note validation requests (i.e. checking that notes indeed exist in the note hash tree). We achieve this by migrating from sequential steps to a staged approach.

This continues the trend set by #13107 where we began to split the message discovery process into multiple steps (now modeled by aztec::message::processing from #14567), each of which starts and ends with a capsule array. This lets us consume and produce arbitrary amounts of values in unconstrained Noir functions, without having to deal with the limitations of fixed sized arrays. As of this PR, the process looks as follows:

1. (pxe): contract simulation starts
2. (nr) message discovery calls fetchTaggedLogs oracle
3. (pxe) log discovery is performed by comunicating with the node, logs are placed in a capsule arrray
4. (nr) each log is read from the capsule array, decrypted, decoded and processed. note validation requests are placed in a capsule array. pending partial notes are placed in a capsule array.
5. (nr) pending partial notes are processed one by one (slow)
6. (pxe) note validation requests are completed by comunicating with the node (in parallel!)

This pattern sidesteps having to deal with fixed-size oracles (which would require e.g. pagination, an even more stateful PXE) by leveraging the capsule array as the main building tool. It should be simple to later extend this to e.g. produce a capsule array of tags to be searched for, which would result in a second capsule array being populated with the results, so that partial note completion log queries need not be completed serially.

The obvious downside of this approach is that it introduces relatively strange oracle semantics, and results in comunication from the contract and pxe to occur not just through the oracle interfaces, but also the values in the capsule arrays (including their serialization).