Split client interaction commands into a `forc-client` plugin

[mitchmindtree]

The aim here is the separation of two major kinds of functionality currently provided by forc:

1. Managing Sway code projects / hosting plugins (init, clean, check, build, update, plugins). This is the role of the standalone forc binary.
2. Interacting with a Fuel node as a client (deploy, run). This would be the role of a forc-client plugin.

One of our primary upcoming priorities is integrating wallet support into the deployment process. Before we add this integration to deploy and run and further bloat the standalone forc tool, it makes sense to separate this client functionality into a dedicated crate.

By keeping the client interaction logic in a dedicated crate, we'll likely also greatly improve the build times and binary size of the standalone forc tool.

To-do

• [ ] Create a forc-client plugin crate under the sway repo's forc-plugins directory.
• [ ] Move the forc deploy and forc run commands to the forc-client crate.
  • Note: this will be the first forc plugin that provides more than one new forc command. To achieve providing multiple commands under a single crate, the best approach might be to declare multiple [[bin]] targets under the forc-client manifest with a separate main for each command. Before diving into this, we should consider checking how the cargo-edit crate (which provides the cargo add, cargo rm and cargo upgrade commands via the installation of a single cargo-edit crate) achieves this.
• [ ] Update E2E tests that use the deploy, run commands.
• [ ] Update Sway documentation.
  • The forc chapter documentation should for the most part be an automatic update, but we may need to add a file stem for the new plugin. We should also review the rest of the Sway docs.
• [ ] Ensure forc-client is published and shipped with fuelup
  • This will include:
    1. Ensuring the new plugin is published under the release assets along with forc and the rest of the plugins and
    2. Ensuring fuelup is aware of the plugin and distributes it in each of the toolchains. I believe this should be automated for the most part, but it may be the case that we need to update a list of plugin names or similar somewhere in fuelup to make it aware.

---

cc @adlerjohn I know we briefly discussed splitting out forc deploy into a forc-deploy plugin in our roadmap chat, but it occurred to me that it might be useful to treat this as a general forc-client plugin that acts as the home of any commands that interact with a fuel node generally, I.e. any command that initalises a fuel client with FuelClient::new(node_url). Does this sound OK?