Changes to support integrating into monolithic build

[Blzut3]

Just about ready to submit the GZDoom overhaul with ZMusic as an optional submodule. Here's the changes it required on this side of things.

• Supports using a ZLIB::ZLIB target that's provided by the parent project. If the parent is vendoring zlib then we don't want to call find_package.
• ZMUSIC_INSTALL variable can be set to disable the install rules. I thought we could get away without this since EXCLUDE_FROM_ALL kind of disables the rules, but the install(EXPORT) imposed very restrictive requirements on the zlib target. I could have just excluded these particular rules when we're being vendored, but figured if we're going to need a variable like this anyhow we may as well allow all the rules to be disabled.
• When building a static library on Windows the dllimport/dllexport attributes should be disabled.
• Interface include directory was missing when vendored.
• Not really related to using with add_subdirectory, but added support for passing source files to use_fast_math (this is for GZDoom/Raze, although they will obviously have a copy of ZUtility.cmake themselves so just keeping things in sync)

[coelckers]

Will this still work with Raze or does it require the altered project for GZDoom?

[Blzut3]

It could probably be integrated as-is, I don't think there's any relevant leaky global state in Raze that would cause issues. Right now though my plan is to begin overhauling the Raze project like the GZDoom PR once that's approved and adding the submodule would obviously come with that.

[Blzut3]

Just realized what you were actually asking after I hit submit. This doesn't change anything about the standalone build of ZMusic except that building a static library on Windows works correctly.