Crates which depend on old versions of `gcc` (now `cc`) do not build on Windows

[ecstatic-morse]

~~The pkg_config utility is nominally cross-platform, so successfully building crates which use it--usually via a utility crate like pkg-config-rs--should be feasible. However, such crates don't currently build (e.g. tcod-sys). This will probably not be as simple as installing pkg_config via a package manager, but that is a good start.~~

The actual issue is that older versions of the gcc crate did not emit the /Fo flag to tell cl.exe where to put object files created during compilation, and thus object files are created in the working directory. These object files are cleaned up after compilation, so this usually doesn't matter, but since the working directory (which contains the crate's source code) is mounted read-only in the container, cl.exe can't create them. Curiously, this only results in an error when the linker goes looking for the object file, not when cl.exe tries to write it.

I don't think there's a good work-around besides mounting the working directory as read/write instead of read-only. I think this is probably not worth it, but I'll let @pietroalbini have the final word.

[ecstatic-morse]

See this issue for some more background.

[ecstatic-morse]

Ugh, it appears that the release of gcc (v0.3.53) used by tcod-sys has the code to emit /Fo. TARGET is set correctly as well. Not sure why it doesn't end up on the command line.

In any case, I can reproduce this when compiling on the host with tcod-rs v0.12.0. The working directory is populated with object files after building.