Add support for dev shells

[kylewlacy]

"Dev environments" is one of the features listed on https://brioche.dev/, so it's definitely a goal of the project to support them natively! There's a few standalone pieces that can be used to make a "DIY dev shell" today, but Brioche itself doesn't have any direct support for them yet.

The exact design is up in the air, but a few bullet points we should hit:

• You should be able to add something like export function shell to your project.bri file, then get access to a dev shell
• You should be able to activate the shell with a command like brioche shell
  • Open to suggestions here, but I think we'll want the default to be to source a script within your current shell. Therefore, brioche shell as a command would be a shell function instead of an actual subcommand for Brioche
  • Without the custom shell function, we'd still offer some handy subcommands. I'm thinking brioche shell activate (prints a script for your current shell that you can then source manually) and brioche shell enter (starts a new subshell and auto-activates the script... although it's unclear to me how exactly this would work)
• Recipes used in the shell should be able to set environment variables, probably using the same values from brioche-env.d (a.k.a. set by the std.setEnv() function)
• The same shell config should be able to handle whatever the user's preferred shell is (probably based on $SHELL). That is, if the user uses zsh, then using a dev shell with Brioche should also use zsh. For completions, this will probably mean we'll need to manually provide different sets of completions for different shells

---

Okay, here's a basic sketch on one possible approach we could take:

import * as std from "std";
import rust from "rust";
import go from "go";

export function shell(): std.Recipe<std.Directory> {
  return std.devShell({
    dependencies: [rust(), go()],
  });
}

Starting from the top level, std.devShell() could return a recipe with a folder structure like this:

./
  brioche-shell.d/
    shells/
      fish/
        activate
      bash/
        activate
      zsh -> bash
      nushell/
        activate

brioche shell would then get the path brioche-shell.d/shells/$SHELL/activate, and either pass that to the shell binary or just print it out so it can be used with source. Shell-specific features and such would then be handled by the activate scripts produced by std.devShell(). This means we could add support for more shells in the future without needing to make any changes to Brioche itself!

At the most basic level, the activate scripts made by std.devShell() would just set the env vars from dependencies by following the same structure used by process dependencies (i.e. looking at the directory brioche-env.d). activate should also provide some standardized way to deactivate the shell, and probably provide extra things like shell autocompletions or even custom shell functions.

I'm guessing some projects may want to only use a specific shell for their dev shell (say, a pinned version of Bash). In that case, we could e.g. add a symlink under brioche-shell.d/subshell, which brioche shell would recognize so that it knows to spawn a subshell instead of trying to source a script. On the other hand, it'd be easy to create an activate script that just uses exec to switch to another shell...