Multiple-URI support in parse_uri and make_uri

[U65535F]

This pull request addresses the issues raised in #7737 and introduces a new feature to the Monero codebase: multi-URL support for parse_uri and make_uri functions.

Key Changes:

• Fixed loop index misuse (replaced i with j for proper iteration).
• Removed the usage of NA as a filler in certain cases.
• General code cleanup for readability and maintainability.
• Introduced new test cases in uri.cpp to validate multi-URL functionality.

Notes:
This PR was rewritten from the latest Monero repository rather than being forked from the original issue (#7737).
All builds are successfully passing, and existing tests have cleared without any regressions.

Please check for any overlooked issues or mistakes, especially in the multi-URL parsing logic.
Validate the new test cases and suggest improvements to ensure robustness.

[U65535F]

@selsta

[selsta]

Thank you. The URI functional test case fails now. Can you take a look?

https://github.com/monero-project/monero/actions/runs/13057491252/job/36433416280?pr=9756#step:11:1471

[U65535F]

Alright, will ping you when it's done. It seems like I didn't update the python source files to comply with the new updated C++ code.

[iamamyth]

As illustrated by the test failures, this PR would introduce a backwards-incompatible change to the wallet RPC interface, which generally should not be done.

[iamamyth]

Two possible ways to address the compatibility issue:

1. Introduce a new version of the endpoint which works with only the new format, retaining the old one (you could still transform requests to the old endpoint into the new format upon receipt and share the address construction code).
2. Modify the endpoint to detect "old format" and "new format" requests, and pick the appropriate logic (e.g. payments field present implies new format, or address field present implies old format).

[U65535F]

@selsta @iamamyth So after a long trial and error, I've managed to reach all the requirements. It passes all the tests and is backwards compatible (fully or partially based on how you view it). The new format is basically the old format but for the multiple values, they're separated by a delimitter which in this case is a ;. On the backwards compatibility, there is a structural change and thus it changes the way you access the data.
For single tx:

res.uri.address
res.uri.amount
res.uri.recipient_name

becomes

res.uri.payments[0].address
res.uri.payments[0].amount
res.uri.payments[0].recipient_name

The rest of the data, that is:

res.uri.payment_id
res.uri.tx_description

remains the same.

To overcome this, I could introduce a new legacy data type and slightly change the code to adjust it. Other than this, what do you think?
If you think every thing is okay, I'll remove the draft state.

[U65535F]

@selsta Please have a look at the code and tell me if to make it ready for review since it's a draft.

[U65535F]

@selsta @iamamyth ping

[U65535F]

@selsta ping.

[selsta]

I will take a closer look within the next days.

[U65535F]

I will take a closer look within the next days.

Alright. I won't ping you till Sunday, but don't forget to reply.