Add a way to override the resultant Python package version

[DavidAntliff]

Currently, maturin build uses the project.version field from Cargo.toml to version the resultant Python package.

Using this version is not recommended by the Cargo team, as it has a specific crates.io purpose, and allegedly should not be overloaded as a general "version" number for a project: rust-lang/cargo#6583

I suggest a feature to enable override of the version number that maturin build (and maturin develop) assigns to the resultant Python package, so that alternative versioning schemes can be used.

As of today, the only way I can find to influence the Python package version seems to be to modify project.version prior to build, such as via sed in a CI script, but this does not work well for local workflows such as developer builds where a CI version number is not available. It also marks Cargo.toml as modified which can have side-effects for source control. Modifying source files is not considered proper in reproducible build environments like "yocto" or Debian package system, either, where upstream source files need to be considered authoritative.

So I suggest that there could be a new way for the environment (e.g. shell environment, or script that invokes maturin) to modify the resultant version number without modifying source files.

[ia0]

Note also that if cargo build reads its own version (which is the case when writing a CLI with clap for the --version flag), then the workaround of editing the Cargo.toml doesn't work, because we want the crate version for the CLI but the Python library version for the Python package.