feat(stdlibs): add package crypto/bech32

[Villaquiranm]

Related to #1475

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: Villaquiranm/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[n2p5]

This looks really good, I have a note on a comment you left in the code, but it otherwise seems like a pragmatic and straightforward PR.

Open question here: For libraries that we port from go -> gno. Do we have an established pattern where I can use some reference data, expected inputs and outputs, and run both the go and gno implementations to show that I get the exact same outputs between both systems? It seems like this would be a really nice way to prove feature parity.

[n2p5]

This comment either needs context that you changed const -> var, or the comment should be removed and become its issue tracked on why this behavior does not work. This way, the coding implementation stays clean.

From an implementation standpoint, I don't see a problem with this being var since it is scoped to the test itself and, therefore, doesn't need a note. It is an interesting question to explore on its own merit though.

[Villaquiranm]

Hello, thanks a lot for the review :)
yeah I add that in order to give some context on my change

I prefered to leave a comment instead of just changing const -> var without an explanation
I think there is an issue to be created, but the issue make sense only if the code is merged.

I agree with you and I'll remove this comment as soon as the Issue is created but I don't really know like do I create the issue right away ? or we wait for the PR to be close to be merged ?

[n2p5]

Right, but if we are to leave the comment, the comment needs to mention that you've changed this from const to var in the comment. if you look at only the lines added and not the lines removed, it doesn't let the reader know that you've replaced const with var. So, if you leave the comment, consider elaborating on the context.

The reason I think removing the comment is that const doesn't provide any additional safety here. This lives inside of a testing file and we don't have to worry about mutation here.

[Villaquiranm]

Sorry you're right, I thought I specified that change...
Improved the (temporary comment, I hope) on bf2167b

[jefft0]

Removed the review/triage-pending label because this PR was reviewed by core dev n2p5.

[n2p5]

LGTM