run.linkerd.io/install can corrupt installs

While trying to explain to someone that run.linkerd.io/install safely installs the linkerd binary without potentially corrupting an existing one, i realized there's a subtle problem: Our `mv` may not be atomic.

https://github.com/linkerd/website/blob/6d29e3a58a82838f3114db3aae338aa51769c3d8/run.linkerd.io/public/install#L13

On most modern OSes /tmp and $HOME exist on different devices, so that

https://github.com/linkerd/website/blob/6d29e3a58a82838f3114db3aae338aa51769c3d8/run.linkerd.io/public/install#L34-L37

is not guaranteed to be atomic. So if a user hits `^C` during an install, they can be left with a `linkerd` binary that is partial.

If we change the `mktemp` to use a temp directory in the `$HOME/.linkerd2`, we can ensure that the `mv` is atomic; however, this would mean that the installer would have to be responsible for garbage-collecting these tmp directories.

I suppose it could also be okay to close this as wontfix if we provided safe alternatives (i.e. via homebrew, apt-get, etc).

Read run.linkerd.io/public/install, especially the mktemp command and the mv at lines 34-37, to understand how the installer stages and replaces the linkerd binary. Confirm the interruption behavior and determine whether the install can guarantee an atomic replacement or needs a documented safe alternative; done means an interrupted install cannot leave a partial binary.

Written by the indexing model from the issue text.