feat(upgrade): Provide table view for upgrades

[epage]

This provides a cargo outdated-like UI, reducing the need for one
extra tool and helps raise visibility into cargo-upgrades decisions in a
pretty way (compared to lines and lines of warnings).

In doing so, I noticed that we mark more dependencies as compatible than we should so shifted the order of things so we wouldn't do so when the version req will remain unchanged.

I also tweaked some of the error handling language to open it up to errors possibly being functionality gaps in cargo-upgrade.

I do wonder if we should sometimes elide dependencies (and suggest --verbose to show them).

For clap:

    Updating 'https://github.com/rust-lang/crates.io-index' index
    Checking clap's dependencies
name              old req        locked latest new req        note
====              =======        ====== ====== =======        ====
clap_derive       =4.0.0-alpha.0 -      -      =4.0.0-alpha.0 pinned
clap_lex          0.2.2          -      -      0.2.2
bitflags          1.2            1.3.2  1.3.2  1.2            compatible
textwrap          0.15.0         0.15.0 0.15.0 0.15.0
unicase           2.6            2.6.0  2.6.0  2.6
indexmap          1.0            1.9.1  1.9.1  1.0            compatible
strsim            0.10           0.10.0 0.10.0 0.10
atty              0.2            0.2.14 0.2.14 0.2
termcolor         1.1.1          1.1.3  1.1.3  1.1.1          compatible
terminal_size     0.1.12         0.1.17 0.2.1  0.2.1
backtrace         0.3            0.3.66 0.3.66 0.3
once_cell         1.12.0         1.13.0 1.13.0 1.12.0         compatible
trybuild          1.0.18         1.0.63 1.0.63 1.0.18         compatible
rustversion       1              1.0.8  1.0.8  1
trycmd            0.13           0.13.4 0.13.4 0.13
humantime         2              2.1.0  2.1.0  2
snapbox           0.2.9          0.2.10 0.2.10 0.2.9          compatible
shlex             1.1.0          1.1.0  1.1.0  1.1.0
static_assertions 1.1.0          1.1.0  1.1.0  1.1.0
note: Re-run with `--pinned` to upgrade pinned version requirements
note: Re-run with `--to-lockfile` to upgrade compatible version requirements
warning: aborting upgrade due to dry run

Fixes #750

[CAD97]

I consider this probably enough to close #750.

I do wonder if we should sometimes elide dependencies (and suggest --verbose to show them).

I think it makes sense to elide locked == latest when run in non-verbose mode, perhaps with a note: unchanged: line.

But I think it also makes sense that --pinned/--to-lockfile communicate intent that should unelide when

• --pinned: unelide where note == pinned
• --to-lockfile: unelide where locked != new

Another column for latest compatible may also make sense, or perhaps change latest to latest compatible when using --to-lockfile.