feat: add note attachments getter APIs

[PhilippGackstatter]

This PR adds accessor APIs for multiple attachments.

• Remove attachment return parameter from get_metadata kernel APIs.
• Add get_attachments_commitment kernel APIs - this returns the commitment over all attachments of a note.
• Add various lower and higher-level procedures for working with this API more conveniently (unhashing attachments into its attachment commitments, and unhashing an individual attachment commitment into its data)
  • find_attachment is the most convenient one and should generally be used. Example usage in network_account_target::active_account_matches_target_account.
• As long as we have no kernel-level support for specifying that a certain attachment scheme can only be added once per note, we need to pick a canonical network account target attachment from the list of attachments, and for now this is the first one.
• This PR does not yet address many of the previous PR's comments (docs, memory layout, renaming, max attachment elements per note validation, ...). There will be another PR that deals with these follow-ups.

part of #2555

[mmagician]

As long as we have no kernel-level support for specifying that a certain attachment scheme can only be added once per note, we need to pick a canonical network account target attachment from the list of attachments, and for now this is the first one.

Why would it be desirable to restrict that a note can only carry one attachment of a particular scheme? If this is for the NTX builder to pick up "network notes", I think the builder could still scan all attachments (since there's only four I think that's ok?)

[mmagician]

LGTM!
There are a few comments still but I'm approving already, assuming that the following get resolved:

• the test for "retrieves the correct attachment data" should verify the actual data is correct (also maybe at least one of the attachments should be >1 word?)
• naming of write_attachments_to_memory procedure