Add new c-bindings feature flag

[landonxjames]

The c bindings generated in build.rs were causing issues for some sandboxed builds. This PR introduces a new feature flag c-bindings that allows building those bindings to be opted in to. It is off by default. This would technically be a breaking change for anyone using the c bindings, so we could instead make it a default feature that can be disabled if that is a worry.

[lierdakil]

This would technically be a breaking change for anyone using the c bindings

Not really, because AFAICS the bindings are already checked into the repo and bundled with the crate.

Also, the name of the generated file was changed in 8bf7a42 since the last release, so the next release will be breaking for anyone using C bindings anyway 🤷

Unless I'm missing something, there's no reason not to disable binding generation by default.

[landonxjames]

Note after some digging it looks like our internal build issues were caused by some unexpected behavior in the cbindgen crate around cargo metadata. See this issue for more context: mozilla/cbindgen#666. We are still trying to figure out a way around that, but I think having the bindings be optional here would still be helpful to everyone.

[dpc]

Don't build scripts need to use CARGO_FEATURE_<name> env var? https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts

[landonxjames]

I also thought that, but this SO question clarified (and this worked locally for me). It doesn't seem to be documented anywhere that I could find.

[dpc]

Huh. Good to know. Thanks!

[jrandolf]

How about:

1. Removing the build script.
2. Creating a test that creates the binding and diffs it against the working directory's crc64fast_nvme.h.
3. If it fails, then you can pass an env-var to recreate the binding (or just recreate it automatically since it's likely the only action to take.)

[ntrinquier]

How about:

1. Removing the build script.

2. Creating a test that creates the binding and diffs it against the working directory's `crc64fast_nvme.h`.

3. If it fails, then you can pass an env-var to recreate the binding (or just recreate it automatically since it's likely the only action to take.)

@jrandolf I gave it a try in #9, I will leave it to the maintainers to decide what option they prefer.

[onethumb]

The implementation in #9 is better, imho, and has been merged in https://github.com/awesomized/crc64fast-nvme/releases/tag/1.2.0. Thanks all!