Refactor note data memory layout

We should consider refactoring both consumed and created note data layout such that data is structured in such a way that aligns with kernel access / usage patterns. See comments below:

[comment link](https://github.com/0xPolygonMiden/miden-base/pull/74#discussion_r1160428627)
> I wonder if we should arrange this a bit differently so that metadata and hash are next to each other. Specifically, it could go like this:
>
> ```
> const.CONSUMED_NOTE_METADATA_OFFSET=0
> const.CONSUMED_NOTE_HASH_OFFSET=1
> const.CONSUMED_NOTE_CORE_DATA_OFFSET=2
> const.CONSUMED_NOTE_SERIAL_NUM_OFFSET=2
> const.CONSUMED_NOTE_SCRIPT_ROOT_OFFSET=3
> const.CONSUMED_NOTE_INPUTS_HASH_OFFSET=4
> const.CONSUMED_NOTE_VAULT_ROOT_OFFSET=5
> const.CONSUMED_NOTE_ASSETS_OFFSET=6
> ```
>
> It seems a bit cleaner and may be useful in the future for computing parent node of note metadata and hash.

[comment link](https://github.com/0xPolygonMiden/miden-base/pull/74#discussion_r1160428962)
> To keep consistency with the previous comment, maybe the order should be:
>
> ```
> const.CREATED_NOTE_METADATA_OFFSET=0
> const.CREATED_NOTE_HASH_OFFSET=1
> const.CREATED_NOTE_RECIPIENT_OFFSET=2
> const.CREATED_NOTE_VAULT_HASH_OFFSET=3
> const.CREATED_NOTE_ASSETS_OFFSET=4
> ```

Something else to consider is the way in which we compute the commitment for consumed notes. This is computed as a sequential hash over all (nullifier, script_root) tuples. I wonder if we could modify the layout / hashing patterns such that nullifier and script root are stored next to each other. This may allow us to use the `mem_stream` operation when computing the consumed notes commitment.

```
const.CONSUMED_NOTE_METADATA_OFFSET=0
const.CONSUMED_NOTE_HASH_OFFSET=1
const.CONSUMED_NOTE_NULLIFIER_OFFSET=2
const.CONSUMED_NOTE_CORE_DATA_OFFSET=2
const.CONSUMED_NOTE_SCRIPT_ROOT_OFFSET=3
const.CONSUMED_NOTE_SERIAL_NUM_OFFSET=4
const.CONSUMED_NOTE_INPUTS_HASH_OFFSET=5
const.CONSUMED_NOTE_VAULT_ROOT_OFFSET=6
const.CONSUMED_NOTE_ASSETS_OFFSET=7
```