Temporary workaround to avoid dropping a tokio::runtime while another…

… is running

This fixes the following error from `wrangler tail`:

```
$ wrangler tail
🦚  Setting up log streaming from Worker script "test-project". Using ports 8080 and 8081.
This may take a few seconds...

Oops! wrangler encountered an error... please help Cloudflare debug this issue by submitting an error report (/home/jnelson/.wrangler/errors/1625847335787.log)

To submit this error report to Cloudflare, run:

    $ wrangler report

Closing tail session...
Error: panic
```

The panic in that file is "Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context."
The larger issue is that there are many different runtimes in Wrangler:
- A runtime created by `wrangler tail` to watch for changes
- A runtime created by `reqwest::blocking` to fetch the account ID from Cloudflare's API
- A runtime in `commands::dev::gcs` - not sure what this does, something to do with a persistent server?
- A runtime in `commands::dev::edge` - ditto

Having more than one runtime going at once is not great; the three in Wrangler
seem to be disjoint, but the one in cloudflare_rs absolutely overlaps with some
of the ones from wrangler.

This is a temporary workaround to avoid panics in `wrangler tail`, but I'm
working on a larger fix to cloudflare_rs to see if it can avoid spawning a new
runtime for each request.

src/tail/mod.rs

@@ -43,6 +43,10 @@ impl Tail {
         is_cloudflared_installed()?;
         print_startup_message(&target.name, tunnel_port, metrics_port);
 
+        // Loading the token creates a nested runtime because it goes through reqwest.
+        // Make sure it's loaded before creating our own runtime; nested runtimes will panic.
+        target.account_id.load()?;
+
         let runtime = TokioRuntime::new()?;
 
         runtime.block_on(async {