Recommend using `metadata_into_tag`

PR https://github.com/0xMiden/protocol/pull/2871 implements `metadata_into_tag`, a helper for extracting the note tag from a metadata header.

Recall the metadata encoding:

https://github.com/0xMiden/protocol/blob/853aeacc71103136ab7c2f8ec9e79e3a66c66913/crates/miden-protocol/src/note/metadata.rs#L128-L134

Technically, element 2 in the metadata header can be directly interpreted as the tag. Since we want to reserve the upper 32 bits for future use, we cannot actually start using them if all code interprets the full felt as the tag, as any of the upper 32 bits set to 1 would no longer make the whole felt equivalent to the tag. This would make these 32 bits useless for us.

So, we need to get users to use the extractor procedure `metadata_into_tag`, so we can start using the upper 32 bits in the future without breaking anything.

The main question is how we get users to do this. A crude idea is to set one of the reserved bits to 1 starting with 0.15. This would force all current users to notice this issue and (hopefully) convert to using `metadata_into_tag` instead. With the next release after that (or before mainnet at the latest), we can revert this back to 0.

Another thing we can do is add this to the migration guide for the next version.

We could always introduce a new metadata version in the future that uses these reserved bits and maintains compatibility with the "v1 metadata API" by returning them zeroed. However, this implies adding a v2 metadata API.
If we can instead keep the reserved bits "unaccessed" in v1, then we could start using these with a v1 API, too, which would be quite nice, so I'd still do the above.

One problem with these ideas is that these won't prevent anyone from extracting the tag directly and have a working things, once we have switched the value back to 0. This is also true for many other parts, so maybe this is the best we can do.

Any other ideas for achieving this are welcome.