add windows msvc support

[xmclark]

Build on windows, #20. Today, wabt-rs does not compile on windows with msvc. Pretty much all of the pieces are in place. The only thing missing is a little extra glue where we call CMake.

This PR takes inspiration from this comment.

This PR adds some conditional compilation steps when running CMake. Building windows will cause the profile to be set based on the PROFILE environment variable. The rust profile names match the msvc profile names. Thanks to suggestion from @sanxiyn, instead we glob for the wabt.lib and let cmake handle the profile as it does by default.

I don't know of a more elegant solution to conditionally compiling a single builder method call, so I had to duplicate the code. I am open to new ideas.

The call to cargo:rustc-link-search=native= is added to link the library in the correct target folder e.g. target/debug.
The solution has been updated. A new build dependency is added: glob. The solution is pretty simple to understand.

I built on my windows 10 computer. I also added an appveyor config for automated CI builds. It currently builds rust stable with visual studio 2017 only.

---

My implementation seems complicated. I feel like there is a possibly a simpler way to do this. Explicitly setting the profile just for windows adds a lot of extra code. I am looking for feedback!

Open question:
Is there a negative impact to linux builds if the CMake profile is always explicitly set? In other words, do we need to conditional compilation?

Answer: we are going to let cmake handle the profile instead. See new solution above.

[sanxiyn]

I think we can just ignore the profile and look for the library in subdirectories.

let mut out_lib_dir = out_build_dir.clone();
if cfg!(target_os = "windows") {
    let pattern = format!("{}/*/wabt.lib", out_build_dir.display());
    for entry in glob::glob(&pattern).unwrap() {
        if let Ok(path) = entry {
            out_lib_dir = path.parent().unwrap().to_path_buf();
            break;
        }
    }
}

[xmclark]

@sanxiyn thanks for feedback!

Does the profile really not matter? I assumed that it would matter because the ABI might be different between release and debug.

Do you prefer using a glob instead of an explicit path because it will avoid any differences between windows target directories?

I think windows rust will always use the same target folder structure, but I'm not totally sure. This solution would find it regardless. I think the risk of multiple different wabt.lib being generated is pretty low.

[pepyakin]

fwiw, I just enabled appveyor but haven’t had a chance to test it.

[sanxiyn]

The idea is to let cmake crate choose the profile and use whatever is chosen. There won't be multiple wabt.lib since only one profile is built.

xmclark's approach is to compute CMake profile from Cargo profile. It duplicates the same logic in cmake crate (see here) incompletely, for example CMake profile RelWithDebInfo won't be chosen.

[xmclark]

@sanxiyn that is a good point. I see in the docs for cmake that it will infer the profile. I will implement your suggested solution when I get home! Thanks!

[xmclark]

I've updated the PR description. I think this is ready for review.

[pepyakin]

Great! Thank you!

[pepyakin]

oh, wow, didn't know this is a thing!

[pepyakin]

(CI checks pass, I just added a new line to Cargo.toml and skiped checks)