Separate deno graph from deno info

[nayeemrmn]

The deno info subcommand should only output cache info and for a single module at a time. We should have a separate deno graph subcommand for outputting the dependency graph of a module.

1. The use cases for these two things are entirely separate. A large list of dependencies creates a lot of noise to sift through when you are just trying to get the location of a cache file. You never need both of these things at once.
2. It allows more versatility for deno info. I propose that deno info doesn't implicitly invoke deno cache (which it would no longer need to), and should show null cache file paths for uncached modules. You can instead call deno cache <url> && deno info <url> for the current behaviour. This design can be applied to query the state of the cache, which partially satisfies feature requests like [Proposal] Deno command to manage modules in cache #5600.

This would be a 2.0 change.

[nayeemrmn]

This would be a 2.0 change.

It has occurred to me that the output of deno info mod.ts is merely pretty-print... and the API access deno info --json mod.ts is still marked as unstable... it's a strong argument for permitting this change in a minor release with some provisions.

Other than the proposed change the --cert, --import-map, --reload flags would be noop'd and hidden until 2.0 removal.

What do you think? @ry @kitsonk

[bartlomieju]

We should do it as deno info --dont-recurse. @nayeemrmn do you want to take this up?