Derive dlltool path from the linker for Windows-GNU builds

[rdesgroppes]

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