Generic interfaces to standard smart-contracts

[AntonMeep]

At the moment, contract definitions in ton-kotlin.contract module module are nothing to write home about.

• Lite client instance is a part of contract definition. Just a bad design decision. This needs to be fixed in a way that won't force specific paradigm, dependency injection or something else, upon the end user.
• Contracts are bundled together by what they are (a simple wallet, wallet V2, etc) and not what they can do (use seqno, have public keys, send multiple messages at once). This makes it rather awkward to work with specific cases, for example wallet V3 supports sending up to 4 transfers at once, but because V2 doesn't, all of the wallets are dumbed down to "1 message - 1 transfer". Another example are highload wallets, especially V2, which unlike all of the other wallets does not use seqno to protect from replay attacks. This needs to be addressed.
• To create an instance of a wallet, it requires the user to supply a private key. This is wrong, since even without knowing the private key users should be able to query for example wallets seqno. Another use case would be to compute wallets address based on known public key.
  Also, security is also important, where for example wallet application wouldn't have access to private key until the user authorizes using fingerprint scanner.
  This also applies to contracts other than wallets, for example NFT tokens, Jetton wallets, etc. In these cases there's no actual private key involved. For example, anyone can get nft item's information, but to transfer it, a wallet (or some other contract) with the address equal to items owner address is required.

This issue requires careful design of such an API, in a way where it would be extensible, yet simple and clear.

For reference, take a look at my failed attempt at this #26, where I attempted to solve it without giving much thought to it. Another example would be this package in an open source tool of mine, where I attempted to implement fluent DSL-based API for wallet v3r2. However, adapting it to all of the kinds of contracts we are dealing with wouldn't be an easy task