Support cargo new/init --force

[dwijnand]

Fixes #3832

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

I haven't really personally given any thought to this and that's quite an old bug, @dwijnand mind expanding a bit on what this is doing? Could you document a bit the new semantics, how it works, and how it's intended to be used?

[dwijnand]

Sure!

So right now there are two fast-fail checks in cargo new and cargo init (fs::metadata(<target dir>).is_ok() and fs::metadata(&<cwd>.join("Cargo.toml")).is_ok(), respectively) and all this patch is suggesting is to add a --force flag (much like cargo has for install) to override this check.

I added two tests that assert that calling cargo new --force against a directory that already exists exits without failure, and calling cargo init --force inside an already initialised crate exits without failure.

The intention, as captured by #3832 and that I share, is to be able to re-initialise a crate when one is created or initialised with the wrong crate type (bin/lib). I've almost got my muscle memory well-trained, but I suggesting with this patch that this be possible out-the-box.

(I'm fine with this being rejected, no hurt feelings.)

[dwijnand]

Maybe this isn't worth the brain cycles.