Setting HASURA_GRAPHQL_ENDPOINT env var can interfere with cli-migrations containers

### Version Information

Server Version: 2.X.X-cli-migrations-v2, 2.X.X-cli-migrations-v3

### Environment

OSS

### What is the expected behaviour?

Cli Migrations image should apply migrations and metadata on container startup.

### Keywords

cli migrations v2 v3

### What is the current behaviour?
If the env var `HASURA_GRAPHQL_ENDPOINT` is set to a value, for example `http://localhost:8087`
the container startup fails with an error like this one:
```
level=fatal msg="version check: failed to get version from server: failed making version api call: Get \"http://localhost:8087/v1/version\": dial tcp 127.0.0.1:8087: connect: connection refused"
```

This happens because the script used for startup of the cli migrations images sets the endpoint like this:
```bash
echo "version: 2" > config.yaml
echo "endpoint: http://localhost:$HASURA_GRAPHQL_MIGRATIONS_SERVER_PORT" >> config.yaml
hasura-cli migrate apply
```
The cli running inside the container will then pick up these configurations from the `config.yaml` file.
Of course, these settings can be overriden by environment variables,
which is what happens in the `HASURA_GRAPHQL_ENDPOINT` env var is set.

This isn't common, since this env var is exclusively used by the cli. Users may encounter this problem if they mount their entire project env file to their container instead of binding individual variables.

If your docker-compose.yaml file includes the following snippet that binds the entire .env file, it could explain your issue:
```yaml
graphql-engine:
image: hasura/graphql-engine:v2.3.0.cli-migrations-v3
env_file:
- ./.env
```

### How to reproduce the issue?

1. Set the `HASURA_GRAPHQL_ENDPOINT` on a hasura instance that is using a cli-migrations image
2. Start the container
3. Startup fails

### Any possible solutions?

Users should not bind a `HASURA_GRAPHQL_ENDPOINT` env var to their containers.
If the user is doing so, it is most likely not intentional.

I am unsure that we should make any changes in our codebase to address this.

### Can you identify the location in the source code where the problem exists?

Issue happens [here](https://github.com/hasura/graphql-engine/blob/master/scripts/cli-migrations/v2/docker-entrypoint.sh#L82) in config v2 and [here](https://github.com/hasura/graphql-engine/blob/master/scripts/cli-migrations/v3/docker-entrypoint.sh#L73) in config v3

### If the bug is confirmed, would you be willing to submit a PR?

A possible fix would be to user `--endpoint` flags in the script instead of relying on the `config.yaml` file.

I am willing to PR this change if deemed appropriate, but unsure if that should be the way forward.

Inspect scripts/cli-migrations/v2/docker-entrypoint.sh around line 82 and v3/docker-entrypoint.sh around line 73, then reproduce the startup with HASURA_GRAPHQL_ENDPOINT set. Verify that the cli-migrations containers apply migrations and metadata successfully without using the conflicting endpoint configuration.

Written by the indexing model from the issue text.