feat(robo/cli): guided cloudflared setup for static tunnels

[Pkmmte]

Description

Robo.js should have the ability to guide users on how to set up their Robo.js project with Cloudflare tunnels that remain static. This way, future --tunnel calls route through a static hostname rather than a dynamic one.

Process should be at least twice as simple as using the cloudflared CLI binary and less verbose. This means we'll need to mask the process just like we already do when creating free tunnels via the --tunnel flag.

Requirements

• No extra NPM dependencies please, unless they're strictly devDependencies.
• Contain as much as possible within the existing /src/cli/utils/cloudflared.ts.
• Only Node APIs. Do not rely on OS-specific binaries, unless well tested or abstracted.
• Must be able to able to switch back to free tunnels just as easily.
• Must be able to run multiple projects in different tunnels simultaneously.

Implementation

I've come up with two possible implementations. Each with their pros and cons. Personally, I lean towards the remote option.

Locally Managed

Local credentials would basically involve using the cloudflared binary under the hood and writing more user-friendly messages to login in. Kinda like what we already do to run the tunnels. We'd also be delegating underlying actions, like it opening the web browser to login.

So, basically a new robo tunnel setup command and another to undo it. If done this way, we'll eventually need to move it into the Sage CLI to minimize package size.

Potential Flow

1. Create Cloudflare account and connect domain via browser.
2. Run robo tunnel setup command and wait for it to open browser.
3. Complete Cloudflare OAuth flow.
4. robo dev --tunnel would recognize Cloudflare credentials on local machine and manage it's own local tunnel.

To use free tunnels again, users would need to log out of their Cloudflare account by removing credentials folder.

Aspect	Details
Pros	- This is more familiar to those already used to it. - Standard OAuth UX.
Cons	- Possible issues with inputs and adapting to binary changes. - Users may perceive it as a security flaw, even though we do not receive auth credentials ourselves. - Breaks on separate environments. - Requires dedicated interactive setup command (e.g., robo tunnel setup).

Remotely Managed

Remote credentials would be closer to what we're internally doing at RoboPlay. The cloudflared binary does not need to be logged in. Instead, we'd need a Zone ID (domain) and Cloudflared API Token. We could then use those credentials to run and set up tunnels. Possibly also automate the DNS process.

Potential Flow

1. Create Cloudflare account and connect domain via browser.
2. Create API Tokens for the domain to tunnel with.
3. Add .env variables for API Token and Zone ID. (+ tunnel ID?)
4. robo dev --tunnel would recognize variables and run tunnel with token.

To use free tunnels again, user would simply need to remove those .env variables.

Aspect	Details
Pros	- More automatic and transparent, because all we need would be 2 .env values - More resilient to platform changes - It just works. Environment variables instead of separate setup command.
Cons	- User would need to know how to get API token with correct permission. (Blog post link maybe?)