Fix (and rewrite) dx init/dx new

[Andrew15-5]

Fixes issue in #2788 (comment). I have found few semantic breakages and bugs, but upon trying to fix stuff and dig deeper to get the whole image of what the current state of init/new subcommands is trying to do, I stumbled upon even more bugs and performance issues (calling MetadataCommand from incorrect CWD causes a 2 s slowdown!). Here is my monologue with a little bit more context.

Here I am cooking a new version of those subcommands. The workspace change will be mostly untouched as I'm not familiar with it, and it doesn't overlap with the problem at hand.

The first commit contains a ton of commented code, which most likely breaks the new command (at least in some way). But I fully rewrote (refactored + added a few things) the init command. Had to get an absolute path without resolving symbolic links, so I used a path-absolutize crate (for free). Second commit adds one dev dependency for running and testing commands (including dx), it's pretty small. I rarely wrote tests before, but these once look very nice. I think I balanced abstraction and clarity pretty well.

One thought I now have (since my testing strategy has changed from the beginning) is to put init subcommmand tests to its own file instead of the main one.

Notes (to not forget):

• Currently no way to use non-default branch (tag/revision) when using a cargo-generate template. Need to add/copy branch, tag, revision options from cargo-generate. Should this be a separate PR or it can be included here? It by itself probably will be very small.

[Andrew15-5]

I also added the branch option to be able to use (unmerged) branches from a remote template (git) repository (#2788 (comment)). As a complete set, also added revision and tag options. This will open a possibility for a wider range of reproducible projects/bugs.

[Andrew15-5]

Current implementation of dx init and dx new follows the behavior of cargo init and cargo new respectively. Specifically, how path and name work. This is technically a breaking change, but for most use cases almost nothing has changed. IMO, the most noticeable change is that path is required for dx new. I laid out the problem here.

[Andrew15-5]

Another notes:

• vcs not only practically was set to None in both branches of the condition, but it also was loosely dependent on metadata which feels like not a good thing to do. Moreover, cargo-generate won't create a VCS if already inside VCS. And lastly, if anything, we can have a --vcs option to use it directly as intended.
• the mutual exclusivity of some options is enforced by clap, so I'm not sure if tests for this should be written, but my gut feeling says that they should be, just in case.
• here I'm pretty confident that I set a correct current directory for metadata command, but not on 100%.
• I could've compressed the tests more by substituting repetitive code with a macro, so that it will show panic in the correct place (2 places), but it seems a bit less readable, including more verbose logs.
• maybe use a local (in-repo) micro-template for the tests? This will remove the necessity for Internet connection and that you must pass the --subtemplate option until Default sub template is not automatically used in silent mode (without user interaction) cargo-generate/cargo-generate#1181 is fixed. Reducing things that can go wrong is always better.
• maybe unpin cargo-generate's patch version so that we can automatically get the above issue fixed as soon as it will be available?