Extend config to use `metadata` keys, like build script directives

[epage]

In #11461, we were concerned about stepping on the toes of link metadata when adding new build script directives. #12201 solved this by locking down the old build script directive syntax and making the new syntax only accept metadata explicitly with the metadata key.

In doing this, we overlooked target.<triple>.<links>, see

cargo/src/cargo/util/config/target.rs

Lines 225 to 228 in 74ef21b

	_ => {
	let val = value.string(key)?.0;
	output.metadata.push((key.clone(), val.to_string()));
	}

.

[epage]

I think, being config, we can be more flexible on compatibility and continue to move forward with #12201.

I would propose

• We add a metadata table for consistency and so people have a place to put keys without any risk of breaking compatibility
  • We first have a transition period with an "unused key" warning if metadata is used
• We refactor parse_links_overrides so we're less likely to break it when adding new fields to TargetCfgConfig.
• We refactor parse_links_overrides / build script code so we can more easily ensure we update one when updating the other

I'm being hand-wavy on the refactors, unsure what would help.

[weihanglo]

The proposal of metadata is exactly what is in my mind! Thanks for writing this out.

The refactor could be focused on removing manual deserialization and instead using serde. Not sure how hard it is.