Consider activating the environment without environment variables

Nobody has claimed this yet.

Testing #226

Related https://github.com/microsoft/vscode-python-environments/issues/240?reload=1

The way I was envisioning this working was something like this:

1. Create a symlink in the user data dir for each shell that points at the vscode-python directory
- Every update, this symlink is replaced
- We would own this file and don't need to ask the user to create it
2. Upon opting in to shellStartup, either via manual or as the default UX with a dialog (https://github.com/microsoft/vscode-python-environments/issues/232?reload=1). Add code to each shell script that sources symlink
3. Upon opening a window (maybe other events?), verify the symlinks

Using this approach, the shell scripts can be smarter than just a simple source script and we don't need to pollute the environment (https://github.com/microsoft/vscode-python-environments/issues/240?reload=1). They can also be as verbose as we want it to be and we can keep the calling of the script quite concise since things like exiting when TERM_PROGRAM!=vscode can be inside this script that is a living file and can be changes as we improve the activation logic (https://github.com/microsoft/vscode-python-environments/issues/234?reload=1).

Other thoughts:

- To prevent double activation, you could add an environment variable that declares it was activated. Maybe `$SHLVL` is useful here?
- No environment changes means no more ⚠ icons related to python environments
- We could make it be safe to assume this would only activate when opening a terminal inside VS Code and not sub-shells, so the cwd can be used as the root of the repo to activate
- The change in scripts can be very concise and clear, like a line with a comment followed by a line to source the file, since we can and want to move conditions into the script.