🐛 Cloudflared ignores the initial version of a remote config

**Describe the bug**
Cloudflared ignores the first version of the remote config.

https://github.com/cloudflare/cloudflared/blob/master/orchestration/orchestrator.go#L43

This comment indicates that remote config versions are always superior to `0`, yet a remote configs created via the API starts with version `0`.

**To Reproduce**
1. Create a Cloudflare Tunnel via the API
2. Create a Cloudflare Tunnel remote configuration via the API
3. Run the tunnel with a config file and a credential file

Cloudflared then uses the config file and ignores the remote config.

**Expected behavior**
The initial version of a remote config should be applied by cloudflared.

**Environment and versions**
- OS: Windows Pro 11 21H2 1000.22000.739.0
- Architecture: x86-64
- Version: 2022.6.1

**Log**
`{"level":"debug","current_version":1,"received_version":1,"time":"2022-06-16T14:06:20Z","message":"Current version is equal or newer than received version"}`

**Additional context**
Maybe the `currentVersion` in the `Orchestrator` should be initialized with `-1`. Or maybe the logic should differentiate between local and remote configs more explicitly to ensure that remote configs have precedence. Or maybe the configuration created by the API should start at version `1` when using `PUT /configurations`.

The same thing happens if you create a tunnel via the Cloudflare Teams UI and you do not set a configuration. The configuration exists with version `0`. However, this poses no issue since the config is `null`.

Current workaround is to push an update to the remote config right after creating it. The remote config version is then incremented from `0` to `1`.