refactor: index NoteUpdateTracker by details commitment

[juan518munoz]

Partly tackles #2227

Specifically, it resolves the NoteUpdateTracker followup flagged directly in code:
https://github.com/0xMiden/miden-client/blob/31b387d5ff006b442640275fdd8745062668df6c/crates/rust-client/src/note/note_update_tracker.rs#L226-L229

NoteUpdateTracker now keys all input notes by NoteDetailsCommitment (always available) instead of the NoteId/commitment split, which removes the expected_input_notes map and the InsertCommitted re-keying.

[JereSalo]

I think this is great and I like the simplification. However, there seems to be a roundtrip problem on notes that have lost their note_id information but we still keep that info in the input_notes_by_id index.
This can happen when a note originally had metadata but after being externally consumed we can no longer compute its id, so it's lost and input_notes_by_id gets rebuilt with less information than what it originally had. It's not critical though, I proposed a fix and added a test here if you want to check it out, there's no need to merge it, I just did it in order to effectively check if it was an actual bug or not.

[JereSalo]

Suggested change

	(matches!(
	update.update_type,
	NoteUpdateType::Insert | NoteUpdateType::Update | NoteUpdateType::InsertCommitted
	) && update.inner().is_consumed())
	(update.update_type != NoteUpdateType::None && update.inner().is_consumed())

If you like we could simplify it to this. Though it's completely valid if you prefer to keep it explicit just in case.

[juan518munoz]

Addressed this and comment above in fae267c