feat: deploy parachain

[AlexD10S]

This PR updates pop-cli to support one-command, production-ready parachain deployments.

• Implement logic in the pop up to reserve the paraID, generate specifications, and register the parachain. feat: logic for parachain registration #410
• Parse event to retrieve para ID when reserving it. feat: logic for parachain registration #410
• Improve wallet signing UI to display the wallet balance and the deposit required for reserve and registration. feat: display costs for registration pop-wallet-signing-portal#7
• Ensure a deterministic build for the release. feat: build deterministic runtime #425
• Utilize a proxy for the registration. feat: use a proxy for the registration #427

How to test it
Start the Paseo parachain locally by running:

pop up parachain -f ./tests/networks/paseo.toml

Run pop up in your parachain folder or specify the folder with the path flag

pop up --path ../test-chain --relay-chain-url ws://127.0.0.1:49155

For more information run:

pop up --help 

[codecov]

Codecov Report

Attention: Patch coverage is 69.40299% with 246 lines in your changes missing coverage. Please review.

Project coverage is 75.18%. Comparing base (87a0ab8) to head (3542b59).

Files with missing lines	Patch %	Lines
crates/pop-cli/src/commands/up/rollup.rs	67.52%	45 Missing and 56 partials ⚠️
crates/pop-cli/src/commands/build/spec.rs	61.18%	47 Missing and 12 partials ⚠️
crates/pop-cli/src/commands/call/chain.rs	58.13%	12 Missing and 6 partials ⚠️
crates/pop-cli/src/common/wallet.rs	0.00%	17 Missing ⚠️
crates/pop-parachains/src/build/runtime.rs	87.87%	6 Missing and 10 partials ⚠️
crates/pop-parachains/src/call/mod.rs	69.44%	3 Missing and 8 partials ⚠️
crates/pop-cli/src/commands/up/mod.rs	76.47%	0 Missing and 8 partials ⚠️
crates/pop-cli/src/common/chain.rs	75.00%	0 Missing and 6 partials ⚠️
crates/pop-parachains/src/build/mod.rs	88.23%	0 Missing and 4 partials ⚠️
crates/pop-common/src/account_id.rs	81.25%	0 Missing and 3 partials ⚠️
... and 3 more

@@            Coverage Diff             @@
##             main     #404      +/-   ##
==========================================
- Coverage   75.28%   75.18%   -0.10%     
==========================================
  Files          64       68       +4     
  Lines       14188    14892     +704     
  Branches    14188    14892     +704     
==========================================
+ Hits        10681    11197     +516     
- Misses       2145     2237      +92     
- Partials     1362     1458      +96     

Files with missing lines	Coverage Δ
crates/pop-cli/src/commands/call/contract.rs	80.38% <ø> (ø)
crates/pop-cli/src/commands/mod.rs	25.00% <100.00%> (ø)
crates/pop-common/src/lib.rs	74.50% <ø> (ø)
crates/pop-contracts/src/call.rs	73.25% <ø> (ø)
crates/pop-contracts/src/utils/mod.rs	81.81% <ø> (-0.69%)	⬇️
crates/pop-parachains/src/call/metadata/mod.rs	93.11% <ø> (-0.04%)	⬇️
crates/pop-cli/src/commands/up/contract.rs	40.95% <0.00%> (ø)
crates/pop-cli/src/commands/up/network.rs	6.81% <0.00%> (ø)
crates/pop-parachains/src/relay.rs	82.60% <0.00%> (-0.91%)	⬇️
crates/pop-common/src/account_id.rs	81.25% <81.25%> (ø)
... and 9 more

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[evilrobot-01]

Comments only as still a draft. Suggestions around rollup are simply based on the fact that we have to start somewhere. I think any new code should use rollup. We can then create a separate PR to add aliases etc and then simply rebase this PR as/when.

Also surprised you are using strings over enums - that should be addressed imo.

A few other general observations:

• Not sure we need network if we are specifying -f ? Counter argument is if we are using network then we dont need to specify -f, it could just be pop u n ./network.toml. Or if we rename -f to -n, then pop up -n ./network.toml
• cargo run -- up --help shows a 'smart contract deployment options' section but nothing for rollups?
• we could still have the subcommands (contract, rollup, network), just optional. These can just be command aliases that map into the existing functions for pop up. Help text could be taken from the subcommand when generating the main help for pop up. I cant say what the technical complexities might be tho.
• pop up --path ../test-chain --relay-url ws://127.0.0.1:49155 in the readme doesnt work
• readme should be updated to rollup

[AlexD10S]

• Not sure we need network if we are specifying -f ? Counter argument is if we are using network then we dont need to specify -f, it could just be pop u n ./network.toml. Or if we rename -f to -n, then pop up -n ./network.toml

In my opinion, this approach makes it much clearer for the user: pop up deploys the project, while the network subcommand is used specifically for launching a local network.

We follow the same pattern with pop build, it builds the project, and for more specific logic like building specs, we use the spec subcommand.
That said, I agree that the -f flag can be avoided.