Reconsider versioning scheme

[dtolnay]

For some of your suggestions, I think my hands are tied until the next major version bump. My versioning scheme is tied to Binaryen's, so until they release a new version I can't make breaking changes, bumping from 0.110.0 to 0.111.0. Perhaps tying the crate versions to Binaryen versions will turn out to be a mistake.

I think the best practice here involves semver's "build metadata".

See https://crates.io/crates/libgit2-sys/versions.

For example you might have:

• wasm-opt 0.1.0+binaryen.0.110.0 (initial release)
• wasm-opt 0.1.1+binaryen.0.110.0 (a nonbreaking modification of the Rust side of things)
• wasm-opt 0.2.0+binaryen.0.110.0 (a Rust breaking change without Binaryen update)
• wasm-opt 0.2.1+binaryen.0.110.1 (pulling in a Binaryen nonbreaking update)
• wasm-opt 0.3.0+binaryen.0.111.0 (pulling in a Binaryen breaking update)

[brson]

I was not familiar with build metadata. Seems like a good idea.

I have to decide how to clean up the mess I've already made for us since we're now at version 0.110.0, some projects have already integrated that version, and I don't want to bump to 1.0. Yanking every major version and dropping back to 0.1.0 will probably cause confusion for projects already working with this crate. Bumping just to 0.111.0 will cause confusion because it looks like the binaryen version but isn't.

I'm inclined to bump to 0.200.0 and start fresh. What do you think @dtolnay?

[dtolnay]

I think you should do #93 in the form of keeping wasm-opt as the name of the bin crate, which will include literally no Rust code beyond a dummy main.rs containing just #![no_main], and possibly some rustdoc. Thus it makes sense to keep its versions equal to the binaryen versions from which 100% of its source code comes. Separately you'll make a new crate name for the lib, starting at 0.1.0 + build metadata.