💡Option to disable remote configuration of a Tunnel

When cloudflared establishes a connection to Cloudflare's edge, the origintunnel service sends the remote configuration to cloudflared (if available), and cloudflared happily applies it without a second thought, overwriting the local configuration.

As I will explain below, this can be a problem in some cases. Therefore I propose adding an option to cloudflared that disables remote configuration of a Tunnel.

### Locally managed Tunnels

With a locally managed Tunnel, WARP-routing is disabled by default and must be explicitly enabled by adding the following keys to the configuration file.

```yaml
warp-routing:
enabled: true
```

From what I can can tell, having to explicitly enable `warp-routing` is meant as a security feature. In the event of a Cloudflare account compromise, even if an attacker has access to modify the network routing configuration of the ZT organization, they will be unable to turn the Tunnel into a "jump host" for its private network.

### The Problem: Tunnel Migration

The problem is that, from what I can tell, it is not currently possible to tell cloudflared to ignore the remote configuration.

This means that, even if your Tunnel is locally managed and has WARP-routing disabled, in the event of a Cloudflare account compromise (or a vulnerability in Cloudflare), an attacker can simply convert the locally managed Tunnel to a remotely managed Tunnel and then enable WARP-routing.

While Cloudflare account compromise is unlikely if proper security is in place, it should be possible to take steps to prevent lateral movement in the unfortunate event that it does happen.