Support aliases in 'config add-release-channel' and '--url-source'

[dfordivam]

Add the URIs of known release channels in code, and allow choosing them via aliases.

Ref: #1050

With this its possible to just do 🙃
ghcup -s vanilla install ghc 9.8.3

[hasufell]

This is now a bit confusing, because the config supports the value GHCupURL and StackSetupURL, but none of the other channels.

ghcup-hs/data/config.yaml

Lines 54 to 92 in a32a559

	# Where to get GHC/cabal/hls download info/versions from. This is a list that performs
	# union over tool versions, preferring the later entries.
	url-source:
	## Use the internal download uri, this is the default
	- GHCupURL
	## Prefer stack supplied metadata (will still use GHCup metadata for versions not existing in stack metadata)
	# - StackSetupURL
	## Add pre-release channel
	# - https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
	## Add nightly channel
	# - https://ghc.gitlab.haskell.org/ghcup-metadata/ghcup-nightlies-0.0.7.yaml
	## Add cross compiler channel
	# - https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-cross-0.0.8.yaml
	## Use dwarf bindist for 9.4.7 for ghcup metadata
	# - ghcup-info:
	# ghcupDownloads:
	# GHC:
	# 9.4.7:
	# viTags: []
	# viArch:
	# A_64:
	# Linux_UnknownLinux:
	# unknown_versioning:
	# dlUri: https://downloads.haskell.org/ghc/9.4.7/ghc-9.4.7-x86_64-deb10-linux-dwarf.tar.xz
	# dlSubdir:
	# RegexDir: "ghc-.*"
	# dlHash: b261b3438ba455e3cf757f9c8dc3a06fdc061ea8ec287a65b7809e25fe18bad4
	## for stack metadata and the linux64-tinfo6 bindists, use static alpine for 9.8.1
	# - setup-info:
	# ghc:
	# linux64-tinfo6:
	# 9.8.1:
	# url: "https://downloads.haskell.org/~ghc/9.8.1/ghc-9.8.1-x86_64-alpine3_12-linux-static.tar.xz"
	# content-length: 229037440
	# sha256: b48f3d3a508d0c140d1c801e04afc65e80c0d25e7e939a8a41edb387b26b81b3

ghcup-hs/lib/GHCup/Types.hs

Lines 388 to 393 in a32a559

	data NewURLSource = NewGHCupURL
	| NewStackSetupURL
	| NewGHCupInfo GHCupInfo
	| NewSetupInfo SetupInfo
	| NewURI URI
	deriving (Eq, GHC.Generic, Show)

And the json instances are finicky.

[dfordivam]

I see alias mainly as a convenience for CLI use. And perhaps primarily for ghcup -s <channel> where the expectation is not to even modify the config. As I would expect most users not wanting to add channel in config just for a one off use case.

The GHCupURL is identical to "main", and StackSetupURL has its own purpose.

If we add support of channel alias in config.yaml, then it will be a bigger change, and it will come with the costs of backward compatibility etc.

[hasufell]

It creates inconsistency, because NewURLSource is valid in both the config and in the cli: ghcup -s GHCupURL tui.

Now we have another set of aliases that don't work in the config but in the cli. I have tried to keep both of them in sync as much as possible.

[dfordivam]

Ok, so adding support of channel alias in config.yaml is better?
I can see one case where it would be helpful, on metadata bump users won't need to modify config if they have channel alias in it.

should the JSON accept the string as it is "prerelease" / "vanilla". or is there any need to make it "prerelease-channel", "vanilla-channel", or something else.