feat: Create Pool view

[0x-r4bbit]

This is a Work in progress

Addresses #30

To run with devnet use

AMM_UI_NETWORK=devnet AMM_UI_DEVNET_FILE=/path/to/local-devnet.json LEE_WALLET_HOME_DIR=/path/to/wallet-dir nix run .

The devnet file should be in the following format, for example:

local-devnet.json:

{
  "channelId": "0101010101010101010101010101010101010101010101010101010101010101",
  "sequencerAddress": "http://127.0.0.1:3040",
  "ammProgramId": "6a7fc14b8c4091208b04956113091766a3921eaa802d17d46bdfccac87dd7ebb",
  "tokenDefinitionIds": [
    "1a23fb2d6b4b9de5dd99eabdea87387ba98a18be7c02311e577239b686ca7884",
    "9007fe66e65b3a496aa49fda60cab6ab218b6569b54c2df510806429f37cdfbe"
  ]
}

[3esmit]

Still work in progress, although a lot of progress have been made. Expect things to still be buggy and the code to have architectural smells.

For this to properly be implemented and run smoothly may require some changes in LEZ, SPEL and integration with ATA.
Specifically:

• LEZ support of read Vec(Account), instead of polling several accounts - this happens because for every poll added, or token owned, several reads are necessary, as the state as a whole is scattered over several accounts. It's not huge data, but batching the RPC reads will make it less slow, submitted PR here feat: add bulk public account reads logos-execution-zone#619.
• SPEL: The library does not have a API that allows the encoding of transactions, instead it have a program specific ABI builder from IDLs, which seems fine, but it does not seem ideal to have a tool generating an automated wrapper about IDL, instead I submitted Runtime idl transaction wrapper api logos-co/spel#249 as a option that allows SPEL to encode transactions directly.
• ATA support is a shortcut to identify user owned tokens.

Also, I am still maturing the code itself. As the Create Pool view comes with a lot of details itself, the implementation have a lot of code, specifically on protocol.rs. This file is responsible for the business logic, while the API is responsible just to present information in a user-friendly manner.

Something I took freedom to explore and implement was the automatic decimals of tokens - as the token program didnt had decimals, at least not in the direct code itself (might be in metadata once we standarize it), I analyzed the common decimals used by tokens overall the crypto world versus their total supply. This works only in QML, it's not part of business logic, and the definition is that the higher the total supply available of a token, the more decimals they have - I found this to be a fair way of demonstrating to the end-user how valuable their balance is, compared to the total supply.

Currently the PR include a testnet configuration with a bunch of tokens I deployed in order to test the application, this tokens have several different configurations and name sizes - the configuration only contains the AccountId of the TokenDefinition, the rest is read from LEZ, and statically determined as the normalized PDA pool address.
It also supports devnet with a custom configuration file as envoirment variable.

Additionally, would be very useful to have another issue/pr implementing a TokenProgram UI. I plan on extracting part of this implementation (such as chain detection, wallet and transaction) to a separate PR as a library, however we might want to decide that lez-programs is not the correct place to implement them, instead a proper implementation living on semantically correct actual code owner repository of that APIs.

Implemented