Clean up Kernel Discovery

[DonJayamanne]

1. Stop trying to figure out the Python environment with global pythonn kernelspecs

With global python kernlespecs, the argv simply has python as the path to the executable
We have no idea what python environment should be used.
Instead we

• Use the active interpreter for global kernelspecs
  I.e. if you have a global kernelspec:
• Open folder a, an you have a .ven in that folder (& thats the active interpreter), then then run a notebook against the global kernlespec then we use .venv]
• Open folder b and have a .conda as the local active python interpreter, now if you run the a notebook against that same notebook, then we use .conda
• Now if you you use the termina and run a notebook against that kernel, then Jupyter will use yet another python environment]

Basically we have no idea what to use, and we try to guess these and the logic is flawed (as we assume the active python env is the right one)

Suggestion:

• List python kernels in the kernelspec section of the quick pick
• When users pick these inteepreters we can warn them about the fact that we have no idea what python env is to be used
  From there we can either
• Ask the user to update the kerrnel.json file (or we can do that)
• Or other

Why the change

• The current code added to guess the interpreter complicates the code

1.1 Finding interpreter that matches a kernel based on display name is never going to be accurate

We match kernelspec names against python environments.
See how often we hit this case.
pythonEnvFound: 'matchDisplayName',

2. Remove/delete old kernelspecs Jupyter ext created in global locations

Jupyter ext used to create kernelspecs in global locations, with guids in the names & custom information in the kernelspec files.
We should remove these files.
This way, after a few months, we can remove the old code that ignores these kernelspecs.

3. Cleaner way to hide default kernelspecs

We need a cleaner way to hide them and document in a single place why they are hidden.