feat(gnoland): Define NoopMsg to facilitate the creation of gas sponsorship transactions

[linhpn99]

Update 2024-06-19 : This PR is in the process of refactoring the flow. It will be open for review when completed Update 2024-06-26 : Ready to review

This PR performs the following tasks:

1. Refactor the code structure in the gnoclient directory : remove redundant code, and write reusable functions
2. Introduce a new message type vm.MsgNoop: a type of message that does not trigger any logic processing in the vmHandler
3. Update the logic in the anteHandler to allow the creation of a non-existent on-chain account if it is processed in a valid sponsor transaction (I need to review this part)
4. Define a new concept of sponsor transaction in gnoclient: it is a type of transaction signed twice, first by the person who wants to perform the transaction, and second by the person sponsoring the gas for this transaction. A transaction is considered a sponsor transaction when it contains a vm.MsgNoop as the first message in the list of messages
5. Similarly, support the sponsor transaction feature in gnokey (I am not sure if this is necessary)
6. Implement necessary test cases for the newly added/updated code mentioned above
7. A few demos with gnoclient and gnokey will be uploaded in the comments section below

From Proposal https://github.com/gnolang/gno/issues/2152 :

• Before integrating this pull request (PR) into the main codebase, thorough testing and evaluation are crucial. Once verified, we can explore its integration into an external decentralized application (dApp) to cover gas fees for user transactions.

• Instead of users directly interacting with the blockchain (like sending tokens or calling specific Realm functions), they will engage with a dApp. Users will submit requests to the dApp, which will handle all necessary checks for their on-chain address. If everything checks out, the dApp will sign the transaction on behalf of the user, covering the gas fees.

• Updates to the keeper and banker modules: A NoopMsg has been defined in this PR to skip gas consumption calculation for messages bearing the dApp's signature. These modules will only process messages (e.g., Run, Call, AddPkg, Send) with user-provided arguments, tagging the caller as their on-chain address.

• At the conclusion of the process, users can filter events to track the outcomes effectively.

I greatly appreciate everyone's feedback to improve this feature.

Contributors' checklist...

• [x] Added new tests, or not needed, or not feasible
• [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• [ ] Updated the official documentation or not needed
• [x] No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• [x] Added references to related issues and PRs
• [ ] Provided any useful hints for running manual tests
• [ ] Added new benchmarks to generated graphs, if any. More info here.