GHCup should fall back to older HLS version if I deny upgrading

[fendor]

Is your feature request related to a problem? Please describe.

VSCode starts: new HLS version! I don't want to upgrade right away, press "No" to the update, and then VSCode complains that HLS is not installed, although ghcup list lists an installed HLS version:

> ghcup list
[ Warn  ] New ghc version available. To upgrade, run 'ghcup install ghc 9.2.2'
[ Warn  ] New hls version available. To upgrade, run 'ghcup install hls 1.7.0.0'
   Tool  Version  Tags                      Notes      
...
✔✔ ghc   8.10.7   recommended,base-4.14.3.0 hls-powered
✗  ghc   9.0.1    base-4.15.0.0             hls-powered
✗  ghc   9.0.2    base-4.15.1.0             hls-powered
✓  ghc   9.2.1    base-4.16.0.0             hls-powered
✗  ghc   9.2.2    latest,base-4.16.1.0                 
...                             
✔✔ cabal 3.6.2.0  latest,recommended                   
...                                 
✗  hls   1.6.0.0                                       
✔✔ hls   1.6.1.0                                       
✗  hls   1.7.0.0  latest,recommended
...                                 
✓  stack 2.7.5    latest,recommended                   
✔✔ ghcup 0.1.17.7 latest,recommended  

Describe the solution you'd like

GHCup should fallback to the installed version if I don't want to upgrade right away.

Describe alternatives you've considered

Users switch to PATH and don't let ghcup automatically handle the HLS installation.
I believe this feature is still in the scope of the automatic management solution.

[hasufell]

My opinion is that this feature shouldn't exist at all (asking before download) and that extending its functionality will make the code harder to maintain for little gain. Users can already freeze their toolchain if they need to.

[re-xyr]

[deleted] I thought "pinning the toolchain" meant switching to using PATH and didn't notice at all there was a toolchain property in the extension settings, my bad.