feat: guide user to call a parachain

[AlexD10S]

This PR introduces the pop call parachain command, providing guidance for users to interact with a parachain in specific use cases, such as creating an asset, nfts, and other interesting developer focused actions.

┌   Pop CLI : Call a parachain
│
◇  Which chain would you like to interact with?
│  wss://rpc1.paseo.popnetwork.xyz
│
◆  Select the extrinsic to call:
│  ● Create an Asset (Assets)
│  ○ Mint an Asset 
│  ○ Create a NFT Collection 
│  ○ Mint a NFT 
│  ○ Transfer Balance
└  

The initial approach was to parse all metadata, allowing users to call any extrinsic or query all storage. However, after testing and discussions, we realized this could generate unnecessary noise, as developers might not need access to everything. Additionally, the input of parameters wouldn’t be as intuitive or visual as Polkadot JS. As a result, focusing on specific use cases that developers can leverage during development seems more practical and valuable.
Additional use cases can be added in the future.

If the chain selected by the user doesn’t support certain operations, those options will not be displayed. For example:

┌   Pop CLI : Call a parachain
│
◇  Which chain would you like to interact with?
│  wss://rpc.polkadot.io:443
│
◆  Select the extrinsic to call:
│  ● Transfer (Balances)
└  

To enable more experienced developers to quickly execute supported extrinsics, pop-cli also offer a the command-line interface for direct execution. For example: pop call parachain --pallet Nfts --extrinsic mint --args 0 0 5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty None --url ws://127.0.1:64966 --suri //Alice

Pending: To Be Finalized After High-Level Review

Unit tests of the functionality is still missing. And a refactor to use the statically generated interface instead of dynamic one.

[brunopgalvao]

Preliminary UX Feedback:


◇  Which chain would you like to interact with?
│  wss://rpc1.paseo.popnetwork.xyz

How does the user know what Pop CLI supports for chain calls? e.g. minting NFTs, minting assets? etc.

Make the UX around what is possible to do on Polkadot, and secondarily, what chains support those operations.

For example:



◆  What would you like to do on Polkadot?
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└  


◆  Supported Polkadot chains:
│  ● Pop Network
│  ○ Phala
│  ○ Acala
│  ○ Moonbeam
│  ○ Custom RPC
└  



◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


[AlexD10S]

Preliminary UX Feedback:


◇  Which chain would you like to interact with?
│  wss://rpc1.paseo.popnetwork.xyz

How does the user know what Pop CLI supports for chain calls? e.g. minting NFTs, minting assets? etc.
 Make the UX around what is possible to do on Polkadot, and secondarily, what chains support those operations.

For example:



◆  What would you like to do on Polkadot?
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└  


◆  Supported Polkadot chains:
│  ● Pop Network
│  ○ Phala
│  ○ Acala
│  ○ Moonbeam
│  ○ Custom RPC
└  



◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


I don't personally like to have a list of chains. The users of this feature are devs, so in my opinion, the pop call parachain command is most useful when devs are actively working on a chain or smart contract and need to interact with it quickly.

For example, if I’m deploying a smart contract on the Pop Network that interacts with an NFT, I would want to run pop call parachain --pallet nft --extrinsic mint to mint the NFT locally or on a testnet with only 1 command. Similarly, if I need to test an XCM call, I may want to quickly fund an account on the relay chain.

For these two scenarios, I believe the current flow works best: first selecting the chain you are working on, and then focusing on the specific use cases available through pop-cli. However, the change in the order you're proposing is relatively easy to implement. So, if we still believe it offers a better DevEx, I can make the adjustment.

[brunopgalvao]

I don't personally like to have a list of chains. The users of this feature are devs, so in my opinion, the pop call parachain command is most useful when devs are actively working on a chain or smart contract and need to interact with it quickly.

For example, if I’m deploying a smart contract on the Pop Network that interacts with an NFT, I would want to run pop call parachain --pallet nft --extrinsic mint to mint the NFT locally or on a testnet with only 1 command. Similarly, if I need to test an XCM call, I may want to quickly fund an account on the relay chain.

For these two scenarios, I believe the current flow works best: first selecting the chain you are working on, and then focusing on the specific use cases available through pop-cli. However, the change in the order you're proposing is relatively easy to implement. So, if we still believe it offers a better DevEx, I can make the adjustment.

If the audience are devs, it makes sense what you are saying:

1. Input a chain RPC URL
2. Show what features are available

I would still have Pop Network as a default, pre-defined chain. So the flow would be like this:


◆  Which network would you like to interact with?
│  ● Pop Network
│  ○ Custom RPC
└  


The following will be shown if the user selects "Pop Network":


◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


The following will be shown if the user selects "Custom RPC":


◆  Enter a custom RPC URL:
│  e.g. rpc1.paseo.popnetwork.xyz
└  



◆  The following features are available on the selected network:
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└