Remove "New Python Installation" option in Configure Python dialog

[corivera]

The current provided python package has gotten pretty old and is nontrivial to update, so we decided to deprecate the New Python Install option. We already automatically detect installed versions of python and also provide a guided experience to install required pip packages, so the only work a user would need to do is install python on their machine before using jupyter notebooks. I improved the automatic version detection as well, so it picks up more recent versions of python.

I also cleaned up some unused jupyter code in the machine-learning extension at the same time, since I already had to make some changes in that area as part of this larger work.

Screenshots of new dialog UX:

1. With python already setup
   

2. When specifying different versions
   

[coveralls]

Pull Request Test Coverage Report for Build 8637291071

Details

• 7 of 12 (58.33%) changed or added relevant lines in 4 files are covered.
• 60 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.02%) to 41.739%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
extensions/notebook/src/dialog/configurePython/configurePythonWizard.ts	0	5	0.0%

Files with Coverage Reduction	New Missed Lines	%
extensions/notebook/src/dialog/configurePython/configurePathPage.ts	1	58.06%
extensions/notebook/src/jupyter/jupyterServerInstallation.ts	59	48.9%

Totals
Change from base Build 8619232124:	-0.02%
Covered Lines:	30721
Relevant Lines:	68888

---

💛 - Coveralls

[corivera]

One question I had is whether it's worth it to still have that first "Edit" UX. Before it was used to cover up all the controls for New/Existing install to reduce clutter when python had already been configured, but now the page looks basically the same either way.

@kisantia Your thoughts?

[kisantia]

One question I had is whether it's worth it to still have that first "Edit" UX. Before it was used to cover up all the controls for New/Existing install to reduce clutter when python had already been configured, but now the page looks basically the same either way.

@kisantia Your thoughts?

To make sure I'm understanding the question - is it if the first screenshot scenario should be removed and it just always be the second screenshot?

[corivera]

One question I had is whether it's worth it to still have that first "Edit" UX. Before it was used to cover up all the controls for New/Existing install to reduce clutter when python had already been configured, but now the page looks basically the same either way.
@kisantia Your thoughts?

To make sure I'm understanding the question - is it if the first screenshot scenario should be removed and it just always be the second screenshot?

Correct

[kisantia]

One question I had is whether it's worth it to still have that first "Edit" UX. Before it was used to cover up all the controls for New/Existing install to reduce clutter when python had already been configured, but now the page looks basically the same either way.
@kisantia Your thoughts?

To make sure I'm understanding the question - is it if the first screenshot scenario should be removed and it just always be the second screenshot?

Correct

That sounds good to me, especially if it helps simplify the code too. Any thoughts on this change @chlafreniere?

[corivera]

I'll make that change in a subsequent PR to keep this one from getting more complicated.