rustup self update fails when RLS using IDE's are open on Windows

[rbtcollins]

Problem
rustup.exe cannot be replaced when an IDE that uses RLS is open on Windows

Steps

1. Install rustup
2. Install vscode
3. Work on a rust project
4. run rustup some time later and get an error about rustup.exe permission denied

Possible Solution(s)
Suggest having a handof/respawn protocol for the proxies so they can be told to GTFO when rustup.exe needs to be replaced.

Proxies should have a file that they look for on disk, which if found, they immediately exit with error. E.g. ~/.rustup/self-updating. We should advise IDEs etc to deal with exiting servers with a few 10's of ms delay - or that they can look for this file and wait for it to be removed before they try to run the command again.

rustup should then kill the proxies reasonably gracefully during update:

1. write the file
2. try the rename
3. look for processes
4. wait p90? p95? for the rustc/fmt/docs etc processes to have a decent chance of cleanly exiting
5. perhaps prompt the user for (kill/wait)
6. kill any with rls or other server style children unless the user has cleanly exited the server
7. loop on 3
8. do the update
9. remove the file

Notes

Output of rustup --version:
Output of rustup show:

[kinnison]

If we rename() the old proxies out of the way before trying to delete them, and then opportunistically silently try to unlink() old proxy names whenever we encounter them, this ought to be a fairly rare event. How does that sound?

[workingjubilee]

@rustbot label: +O-windows

[rbtcollins]

#2441 is more comprehensive