Improved shaderc-sys Build Structure and Fixes

[Josh194]

NOTE: changes are actually quite a bit less expansive than they look; most of the diff is just from rearranging things

Overview

Cleans up search path resolution for shaderc by extracting it into a function (get_search_dir) and replacing the endless cycle of if path.is_none() { path = ... } checks with early returns.

Fixes an issue where path resolution did not line up with the docs; it is documented that the build-from-source feature takes precedence over all other resolution methods, but in reality it only disabled a few last-resort checks and changed a single warning message. Now, this feature actually overrides any attempt at path resolution immediately. Since building from source is still attempted if resolution fails, the associated code has also been moved into a separate function (build_from_source).

REVERTED (see comments)
Finally, the check for MSVC environments when deciding the library name to search for has been removed, and the rustc-link-lib options for non-source-build windows environments now specifically searches for <LIB_NAME>.lib using the :+verbatim modifier to prevent rustc (or the C++ compiler) from changing it. This fixes an issues where windows systems with the Vulkan SDK installed would fail to find the shaderc library during builds (in non-MSVC environments), always forcing a build from source.

Breaking Changes

The build-from-source feature now works as documented. Anyone relying on the old (broken) behavior could see breakage, though this is probably unlikely.

REVERTED (see comments)
On windows, the expected library name during path resolution is now SHADERC_STATIC_LIB_FILE_WIN (shaderc_combined.lib), as opposed to SHADERC_STATIC_LIB_FILE_UNIX (libshaderc_combined.a) in non MSVC-environments.
This does not affect source builds.

Discussion

REVERTED (see comments)
As for the changes to path resolution on windows, I personally think the method here is an improvement over the previous design. At least from the names, the library name constants are clearly meant to be OS-specific; the host compiler should have zero bearing on this (if they are meant to be env-specific instead, they should explicitly name themselves as such). Most noticeably, it certainly has no bearing on the structure of the host Vulkan installation (if any); this is what prevented shaderc-rs from finding the existing libraries before. Note that both clang and MinGW support linking to .lib libraries on windows (or at least the shaderc_combined.lib shipped with Vulkan), though granted I'm not sure MinGW actually has a compatible ABI since I'm assuming the shipped libraries were built with MSVC? It's possible this won't work in practice for MinGW at least, but it should for Clang. Maybe MinGW environments should skip the Vulkan check entirely with a warning?

Still, this could be annoying in some cases. For example it means users cannot always replicate the source-build procedure this project uses themselves (using SHADERC_LIB_DIR) since (at least for me, using MinGW) the underlying shaderc library produces UNIX-style libraries.

If this is a concern, I could easily check for both names on non-MSVC systems instead, which would make at least that change back-compatible.

[Josh194]

Reverted the changes to path resolution for now. If I can somehow get something definitively working I'll make another PR just for that.

[antiagainst]

Thanks!