run-make: investigate if we can make tests with linkage less error-prone

In #128807 we found out that for fmt-write-bloat we needed to do (on Windows):

- #[link(name = "c")]
+ #[cfg_attr(not(target_env = "msvc"), link(name = "c"))]
+ #[cfg_attr(all(target_env = "msvc", target_feature = "crt-static"), link(name = "libcmt"))]
+ #[cfg_attr(all(target_env = "msvc", not(target_feature = "crt-static")), link(name = "msvcrt"))]
extern "C" {}

in order for the test to not be ignore-windows-msvc.

The trouble here is that libc doesn't exist on Windows. Well it kinda does but it isn't called that so we substitute a name that works.

It also can't just be #[cfg_attr(target_env = "msvc", link(name = "libcmt"))] simply, because that would fail with

warning LNK4098: defaultlib 'msvcrt' conflicts with use of other libs

We should find a way to make this less tricky / error-prone (because this is very non-obvious).

@ChrisDenton said

I do think this logic should ideally either be in run-make-support or better yet compiletest could have something like a NO_STD_EXTRA_ARGS variable that any test can use. Or at least I think that's better than individual tests needing to figure it out. But I'm not entirely sure how best to approach that.

Start by comparing the fmt-write-bloat test and the linkage changes from #128807, then inspect run-make-support and compiletest as possible places for shared handling. Determine how a reusable mechanism can cover the Windows MSVC CRT cases without requiring each test to spell out complex cfg attributes. Done means tests no longer need error-prone, duplicated linkage logic while avoiding the msvcrt/libcmt conflict.