Implement Multi-Token Support for Namada Balance Command

[oxatik]

• The current namadac balance command only supports retrieving the balance for a single token. This limitation makes it inconvenient for users who need to manage multiple tokens on the Namada network.

• To improve the usability and functionality of the Namada balance command, I propose implementing multi-token support. This would allow users to retrieve the balance for multiple tokens in a single command, reducing the need for repeated commands and improving overall efficiency.

Proposed Solution:

• Update the namadac balance command to accept a list of tokens as input.
• Modify the command’s output to display the balance for each token in the list.
• Implement a new flag or option to specify the token list, e.g., --tokens or -t.

Example Use Cases:

• Retrieve the balance for multiple tokens in a single command: namadac balance --tokens NAM,UST,ATOM
• Display the balance for all tokens held by a specific owner: namadac balance --owner <owner_address> --tokens all

Benefits:

• Improved user experience: Users can manage multiple tokens more efficiently, reducing the need for repeated commands.
• Increased functionality: The updated command provides more flexibility and customization options for users.

[brentstone]

Thx for the issue submission. This issue is unlikely to be implemented by the current core engineers, but you are certainly welcome to take it on if you'd like. I've got a couple comments:

• Adding the token list probably doesn't provide that much better UX rather than just iterating in a for loop, i.e. for tok in NAM UST ATOM; do namadac balance --token $tok; done
• Having an --all-tokens flag or similar is more interesting. The difficulty is that the current structure of our storage keys is not friendly to doing this operation. Theystorage keys look like <vp_address>/<token_address>/balance/<user_address>, so you would need to iterate over every single balance storage key in the DB in order to find all <token_address>s that are held by a given <user_address>. We would not want to add new storage keys to the DB to support easier look-up at the CLI level. I do believe that the indexers contain this information more efficiently (for serving data to the Namadillo interface, for example)