fix(dist/triple): ensure dist::triple::known is up to date with platforms

[rami3l]

Closes#3783.

By introducing platforms as a new dependency, this PR tries to address both the problems that come with generated source files within src, as well as the issue that the list of known target triples is a moving target:

• Since build.rs already depends on full target triples to work, it no longer has to include!() some file inside src;

  Grepping the whole repo showed that RUSTUP_OVERRIDE_BUILD_TRIPLE has been used only once in the actual business logic, and exactly as a full triple, so this partial triple thing in build.rs is probably not very useful after all?

  rustup/src/dist/dist.rs

  Line 261 in 2a5a69e

  implTargetTriple{

  
  

  rustup/src/dist/dist.rs

  Lines 266 to 268 in 2a5a69e

  	pub(crate)fnfrom_build() -> Self{
  	ifletSome(triple) = option_env!("RUSTUP_OVERRIDE_BUILD_TRIPLE"){
  	Self::new(triple)

  
  rustup component (add|remove) should not rely on hardcoded target triples #3783 (comment)

• The source file containing lists of known target triple segments, albeit generated, is committed directly into the codebase as a regular Rust module to enhance visibility;
• The code generation coherence test is based on a specific version of platforms, so the output will not change as long as platforms' version is locked.

Concerns

• Are custom triples involved in this change? No, they are handled by another mechanism (CustomToolchainName).
• Will the original approach of building a regex of all list members be not scalable?
  

  rustup/src/dist/triple.rs

  Lines 70 to 79 in 2a5a69e

  	let name = format!("-{name}");
  	staticRE:Lazy<Regex> = Lazy::new(|| {
  	Regex::new(&format!(
  	r"^(?:-({}))?(?:-({}))?(?:-({}))?$",
  	LIST_ARCHS.join("|"),
  	LIST_OSES.join("|"),
  	LIST_ENVS.join("|")
  	))
  	.unwrap()
  	});

[djc]

Nice! I have a bunch of small suggestions but this is looking pretty good!

(Sorry for taking a while to review it.)

[djc]

Nice!