make gnoweb aware of r/sys/users

[moul]

We already have basic support for usernames through special rules for strings that match @username in the JS renderer. Currently, these are redirected to r/demo/users:{username}. I expect them to redirect to the upcoming u/{username} (#2189), which will address the concept of user pages globally.

Regarding my comment here: #3283 (comment)

I believe that gnoweb should recognize r/sys/users (#2827) more, and be able to query it. For instance, we should expect the help page to allow std.Address to be formatted as @username, enabling gnoweb to automatically resolve the username and make a maketx call that uses a simple std.Address.

This is already what we do in gnoland by checking and understanding the concept of r/sys/users to enable namespace support when adding a package. Therefore, my proposal is to make gnoweb aware too.

cc @gfanton @leohhhn

[moul]

Example of awareness:

• https://github.com/gnolang/gno/pull/175/files: if @username, create an automatic link to /u/username.
• If it matches g1[a-z0-9]{30}, create an automatic link to /u/address.

Tomorrow, we might consider automatic resolution from js/background, depending on the performance impact; lazy loading of js may be preferable.

[moul]

An interesting approach would be to make gnoland's RPC calls automatically resolve the passed string (primitive type) lazily if the target variable is an std.Address. This change would make the "username" system universal within the gno.land ecosystem, allowing std.Address to function as either a username or an explicit bech32 address.

Alternatively, this could be implemented in gnokey, enabling all gnokey-powered wallets (CLI, adena in the future, gnokey mobile, and any gnoclient-based programs) to automatically use usernames as well.

This would allow contract writers to care less about users, resulting in contracts that do not rely on boilerplate language.