Add setting bios.shell_path

[hugeblank]

Allows the user to directly set the path the bios uses to launch the shell. Setting bios.shell_path takes precedent over bios.use_multishell. Essentially a custom shell may choose to implement shell and multishell APIs, independent of whether use_multishell is set. This is loosely reflected in the description of the setting. Also some additional status checking has been implemented to allow for shell errors to be easily read before computer shutdown.

My justification for adding this is that while unbios exists, it is the logical extreme of what I imagine most players want. This PR is the spirit of unbios in a way that makes sense for CC, that advanced players can take advantage of (if I'm not mistaken mbs could benefit from this too, no?) Also servers presumably would ever so slightly benefit from computers that don't need a whole shell having the ability to start without one.

[SquidDev]

This was previously discussed in #710 and #911, and it's still not clear to me if this is actually useful. I understand the instinctual desire for this, but I don't actually think it ends up solving any practical problem.

[hugeblank]

The utility for me is that I don't have to deal with my own shell (or programs that don't require a shell) being layered atop an existing shell. It just feels like an extra step that should have the ability to be removed, especially when it's dead simple to implement, does not break compatibility, and is entirely up to the user to take advantage of.

[Wojbie]

How does the dead shell impacts anything? Assuming multishell is off and you called shell.exit() in startup code that then initiated your shell it no longer does anything and will exit once your code exits.

EDIT: I guess it is there in call stack but does that really impact anything ?

[hugeblank]

Assuming multishell is off and you called shell.exit() in startup code that then initiated your shell it no longer does anything and will exit once your code exits.

Startup programs wouldn't even be ran, and the shell API would not exist. Those are both things the shell does. Basically any shell.<...> setting would become something the user may (or may not) implement in their custom shell.

EDIT:
#1796 posed an interesting problem regarding startup files that I spent far too long thinking up a couple solutions for. Like I mention in this comment before the edit, startup programs wouldn't even be ran, and as such players wouldn't even be faced with having to deal with the limitations and quirks of the vanilla shell. This is a benefit to the option of having a clean slate for a custom shell.