Add `brioche show` command to view recipes / artifacts

[kylewlacy]

Today, the only tool Brioche provides to view the content of a build is to run brioche build -o <path>, then to inspect the written output on the filesystem. This can be "good enough" in a lot of cases, but it'd be nice if we had some tooling to inspect the results from a build without needing to manually write it to disk first!

We should add a brioche show command. At minimum, it should allow users to inspect recipes and artifacts. Here's a few different use-cases it could cover (we don't have to handle all of these for the initial version though):

• List the contents of a directory artifact: filenames, file sizes, permissions, total combined size
• Show the contents and permissions from a file artifact
• Show the target path for a symlink artifact
• Show a recipe as a JSON or tree view (probably with controls to limit nesting, since recipes can get really large)
• From a recipe, show the artifact that it outputs if known
• From an artifact, show which recipe(s) output it if known

There are other things that a user might want to show too:

• Inspecting artifacts / recipes via the registry
• Inspecting things from the cache
• Inspecting project files

(I'm not sure if brioche show should be overloaded to handle all of the above though! It might make sense to split some of these out into different commands)

[kylewlacy]

One big question: how should a user specify the artifact or recipe to view?

We should allow passing a hash of course, but most of the time, a user would be copy/pasting a hash that was output from another command like brioche build. So it'd be nice if we had other, more ergonomic ways for inspecting recipes.

One easy option: if brioche show is passed a file path, evaluate it just like we would for brioche build and show the recipe(s) that would be baked normally. There's some nuance here, as currently builds can trigger multiple bakes from JS (through functions like .read()). We'd probably want to fail if we encounter an unbaked recipe when doing this (maybe unless a --build arg is passed?), plus that could also mean we'd want to show multiple recipes in that case!

Another option would be to not to evaluate the JS, and to instead track build jobs in the database. brioche show could then "just" show the last evaluated recipe e.g. by file path-- although this may also be misleading since the project files on disk could have changed! I think actually evaluating the JS would be better, honestly.

Oh, and in the case where brioche show takes a project to show recipes from, that also ties into #320