feat: enable creation of proposals based off local simulations

[mds1]

After creating a proposal locally and simulating it to ensure it does what you'd expect, allow users to create that proposal on-chain by calling the propose method. This would make it easier to create new proposals with confidence they do what you expect. Inspired by the ENS EP9 issue.

Steps to implement:

• Implement feat/sim new proposals locally #56
• Decide how to connect wallets. This is the major decision, and there's a few ways it can be done. Unlike deploy scripts, we can't design the propose call to be from a throwaway private key since that won't hold the tokens to delegate. Tokens are often held in hardware wallets and multisigs, so we have to choose an approach with that in mind. Ideally, we can support arbitrary wallets here.
  1. The simplest approach from an implementation perspective is use the existing ethers.js v5 dependency's Wallet class to create an instance from a private key, and use that to sign the transaction. This is strongly NOT recommended because we don't want hardware wallet users exposing their private key like this. Therefore this approach should be eliminated as an option, and is only listed here for completeness
  2. Add Hardhat as a dependency. Since we're already in a TS environment with Seatbelt, adding Hardhat as a dependency is logical. This allows us to leverage the ledger plugin for wallet connections, but I'm unsure if there's a Trezor plugin or ability to support Safes, MetaMask, etc.
  3. Add Forge as a dependency. Similar to (2) this lets us support Ledger, Trezor, and other wallets, but supporting arbitrary wallets like Safes and MetaMask isn't easy here. Because we want to start from the .sim.ts simulation file, this is a bit clunky as you'd need vm.ffi in a forge script to generate the transaction from it.
  4. Add a frontend/ directory to include a very simple frontend app with seatbelt that only runs locally, prompts you to connect your wallet with something like RainbowKit or ConnectKit, and has the .sim.ts transaction ready to sign and submit. This gives the most robust approach with largest wallet support and is probably what I'd recommend. Wallet connection packages like RainbowKit/ConnectKit support pretty much all wallets (Hardware wallets directly or indirectly via MetaMask etc, Safes, all injected web3, etc). The app can either require reading from a .sim.ts during build and only support one sim at a time, or it can have a file chooser interface so you can choose the .sim.ts file dynamically after build. There's likely other approaches here too
• The final step of generating/signing/submitting the transaction is dependent on the previous item, but has a few requirements: Use the exported config object from the .sim.ts file, ensure it has a type of new, validate all inputs, optionally run the simulation use it and require the user to verify that everything looks good, then generate/sign/submit the tx. If we go with approach (4) above, since simulations output an HTML report, it's possible to have a UI that forces the user to read the simulation report before submitting the transaction on-chain (see Look into and document potential modes of operation #39 and feat: npm package the "create proposal" site can use to show simulation reports #66)

For approach 4, there are many templates for this such as as turbo-eth/template-web3-app, m1guelpf/nextjs13-connectkit-siwe, and wslyvh/nexth: A Next.js + Ethereum starter kit to quickly ship Web3 Apps ⚡. Investigate these and consider using one, unless it seems like overkill, in which we can just use create-wagmi to scaffold the project.