In particular, this is an issue if the current project uses Docker integration, since the new stack binary will be installed in ~/.local/bin in the container (and that binary may not be compatible with the host's platform), which is almost certainly not intended since that stack binary won't ever actually be used.

While we could force stack upgrade to disable Docker integration, there are cases where the rest of the project's stack.yaml don't make sense in a non-Docker context and so it would fail. Therefore, better to just have stack upgrade always use the implicit global project in ~/.stack/global-project.

Steps to reproduce:

1. Create a project with a stack.yaml that enables Docker integration
2. Run stack upgrade in the project

Expected results:

stack --version shows that stack has been upgraded on the host.

Actual results:

stack --version on the host is unchanged, since the new stack executable was only installed in the container.