cloudflared access curl integration feedback

The `cloudflared access curl` command ([docs][1]) can be used to obtain a valid authentication token and include the `cf-access-token` header with the curl command line. However there were some integration challenges when naively replacing an existing `curl` invocation by `cloudflared access curl`:

- The subcommand requires the first argument to be the URL. Therefore the invoking script had to be modified to move the URL to the front.
- The saved token is based on the full URL. If `https://www.example.com/download/file.zip` was requested, then the file `~/.cloudflared/www.example.com-download-file.zip-token` would be created. For my use case, I needed the token to be scoped to a domain. Therefore I had to extract the host from the URL and use `cloudflared access login https://www.example.com` instead.
- The very first time authentication happens in the browser, a redirect to the original URL occurs. That was undesirable as the URL was a file to be downloaded. It would be nice if the redirect can be disabled in order to unconditionally display the Success page ("You are now logged in and can reach this application. You can close this browser window."), similar to the displayed message when you are already authenticated.
- The `cloudflared access login` command prints the token. This info is sensitive even if it is only valid for a short time. It is terrible if you are doing a screencast. It would be better if it is hidden, recommending the user to use the `cloudflared access token --app=www.example.com` command instead.
- The `cloudflared access token` command does not validate the token online. The token file appears to have an expiry epoch time in the JWT payload, so at minimum that can be verified if available. However due to potential clock skew and server-side expiration, I ended up with the following strategy:
1. First time? Always call `cloudflared access login https://www.example.com`
2. Obtain the token with `cloudflared access token --app=www.example.com`
3. If the token is empty, fail with an error.
4. Success.
- When the token from `cloudflared access token` is used, a redirect occurs to the login page. Because the final status code is 200 OK, applications which use `curl -sL -Hcf-access-token=$TOKEN $URL` will end up using the wrong data. Perhaps a HTTP status code other than 1xx and 2xx can be used? For example, 400 Bad Request or 403 Forbidden?
- The `cloudflared access curl --help` command fails with `parse --help: invalid URI for request` instead of displaying a synopsis such as `cloudflared access curl [options...] `. The `--allow-request` or `-ar` option is unfortunate, the latter conflicts with curl.

[1]: https://developers.cloudflare.com/access/cli/connecting-from-cli/