Configurable terminal environment activation

[anthonykim1]

Instead of simply removing the existence of terminal env var activation: #24567

In replace of the terminal env var activation experiment, we could build an experience where we can have a proper "hidden/clean" activation without explicitly activating (via manually setting user's environment variables and this is where we had difficult time being confident of whether user's environment was properly activated or not).

Note: Clean/hidden activation represents an virtual environment activation where user would not see the environment+shell specific activate command/scripts run in their terminal visible UI-wise.

To give a gist of the discussion with @karthiknadig :

In the VS Code side (Typescript side) - meaning the Python environment extension side of things, we could set an activation environment variable flag for specific shell (so something like VSCODE_BASH_ACTIVATE) and have it point to the environment specific activation script source ../..etc.

Then add this environment variable via environment variable collection API (already exists in core) => meaning add this environment variable to terminal process when we create terminal.

On the shell script side of things (meaning shell init script such as .zshrc or .bashrc), we would check if the user specifically wanted this "hidden/clean" activation setting.
IF SO we would simply run the "source ./venv/ ..etc" inside the shell init script.

In running "source ...etc" activation command on behalf of user, they will not see this activation command on their terminal and we would not have to worry if their environment is fully activated (via implicitly setting environment variable in the terminal env var experiment case).
But rest ensured their environment will be activated via the existence and execution of "source ..etc" activation command injected into user's shell init script.

Also note that running source activation command automatically will add deactivate script into user's directory so we do not have to worry about setting deactivate script manually.

We would also be able to check the activation state of user via shell environment API: microsoft/vscode#227467