Add fix subcommand

[Jake-Shadle]

This change adds a fix subcommand, which attempts to automatically update cargo manifests to use versions of a crate that are unaffected by advisories.

The algorithm we use differs from the one currently used in cargo audit, as that one only allows patching of direct dependencies, but it's much more likely (especially in larger projects) that the crate which an advisory applies to is a transitive dependency, potentially multiple times, so we instead start at each vulnerable crate and walk up the crate graph until all local/workspace crates have been reached, gathering the set of versions that include 1 or more of the "good" versions of the dependent crate.

Due to the nature of crate graphs, this fix command is basically a best effort of trying to patch as many crates as it can, and printing warnings when it is unable to do so as there are a number of reasons a patch can't be (fully) applied.

1. No new versions of the crate are available or the advisory has not been updated to denote the fix versions.
2. No version of a crate has a published version which has semver compatibility with 1 or more of the versions that are required for the patch, recursively. This will by far be the most likely reason for a partial patch.
3. The semver requirements for 1 or more crates is not compatible. This can be overridden via --allow-incompatible.

This is what a dry run currently looks like, displaying the patch that would be applied by the fix subcommand

Additional changes:

1. Adds support for unsound advisories
2. Changes the logic introduced in Implement multiple advisory databases #244 to support multiple advisory databases, we now use a single root directory (default: ~/.cargo/advisory-dbs) under which each db is placed in a directory with canonicalized format, similar to how cargo places registry indexes

TODO:

Need to fixup error reporting so that it's clear where and why an advisory can't be patched.

Resolves: #242