Derive `dlltool` path from the linker for Windows-GNU builds (#4206)

`rustc` on Windows-GNU shells out to `dlltool` to synthesize import
libraries: for `#[link(... kind = "raw-dylib")]` declarations in any
crate (`windows-sys` 0.61+ is the common case), and for the `*.dll.a`
companion that `cdylib` crates emit alongside their `.dll`.

`cc_toolchain` has no action/tool slot for `dlltool`, since `gcc` used
as a linker runs it internally, but `rustc` drives the linker directly
and so needs an explicit `--codegen dlltool=` pointer, which previously
had to be supplied by hand via `extra_rustc_flags` on every target.

Every MinGW toolchain, whether a native Windows distribution (winlibs,
MSYS2 mingw64, llvm-mingw) or a Unix cross toolchain, ships `dlltool`
right next to the linker with the same naming convention (`.exe`/`.EXE`
suffix or none), so derive its path from the `cc_toolchain`'s own linker
tool path instead.

A user-supplied `-Cdlltool=` via `extra_rustc_flags` still wins, since
`rustc` honors the last `-C<key>=` for a given key.

This adds no new `constraint_value` nor `config_setting` and does not
affect toolchain auto-registration or resolution: `target_abi` is
already parsed from the target triple on the resolved `rust_toolchain`,
the same field `portable_link_flags` and `symlink_for_ambiguous_lib` key
off of a few lines below.

Assisted-by: Claude