Forcing +crt-static on windows: problematic with DLLs?

https://github.com/diesel-rs/diesel/actions/runs/6572883796/job/17854873471?pr=3833#step:9:271

> = note: Creating library D:\a\diesel\diesel\target\x86_64-pc-windows-msvc\dist\deps\diesel.lib and object D:\a\diesel\diesel\target\x86_64-pc-windows-msvc\dist\deps\diesel.exp
>
> LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library

https://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with

> You'll see the error message you quoted when the linker is told both to link to msvcrt.lib (static libc) and libcmt.lib (dynamic libc). Which will happen if you link code that was compiled with /MT with code that was linked with /MD. There can be only one version of the CRT.

You can see `libcmt.lib` getting linked in, while cargo-dist turns on +crt-static on windows, [as recommended by the Rust RFC](https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md#future-work):

> Furthermore, it would have arguably been a "more correct" choice for Rust to by default statically link to the CRT on MSVC rather than dynamically. While this would be a breaking change today due to how C components are compiled, if this RFC is implemented it should not be a breaking change to switch the defaults in the future, after a reasonable transition period.
>
> The support in this RFC implies that the exact artifacts that we're shipping will be usable for both dynamically and statically linking the CRT. Unfortunately, however, on MSVC code is compiled differently if it's linking to a dynamic library or not. The standard library uses very little of the MSVCRT, so this won't be a problem in practice for now, but runs the risk of binding our hands in the future. It's intended, though, that Cargo [will eventually support custom compilation of the stdlib](https://github.com/rust-lang/rfcs/pull/1133). The crt-static feature would simply be another input to this logic, so Cargo would custom-compile the standard library if it differed from the upstream artifacts, solving this problem.

It's possible we should adjust our rule from "always +crt-static" to "+crt-static if there's no system dependencies" or "there's a config flag to turn of this behaviour" (I would have liked to emit this into a persistent/normal rust build config, but +crt-static is in a weird place where there's no right place to put it, really, especially with dynamic-vs-static musl sharing the same target triple while you could reasonably want to support both).

Start with the linked GitHub Actions job and trace where cargo-dist applies the always-`+crt-static` rule for Windows builds. Compare that behavior with the reported MSVC DLL warning and determine how the chosen policy should handle system dependencies or an opt-out; done means the decision is implemented and the affected Windows build no longer emits the conflicting CRT warning.

Written by the indexing model from the issue text.