Identify platform-agnostic flow for sandbox creation

[ebkalderon]

Currently, the instantiation of a new sandbox is handled by delegating Sandbox::spawn() to an OS-specific os::create_sandbox() function. This works, but each implementation of this function is essentially allowed to do whatever it wants without any predefined structure, making it difficult to know where to start when writing a new backend for Bastille.

In particular, it is becoming increasingly clear that the high-level procedure for instantiating a sandbox is similar across Unix-like platforms. Windows support is not currently planned, but could potentially be achieved with WSL, if it adheres to Linux and/or POSIX closely enough. Specifically, the general flow appears to be:

1. Perform some pre-setup steps, e.g. elevate privileges or open any file descriptors you would like to inherit in the forked process.
2. Fork the process, where both the parent and the child receive the same file descriptors from step 1. In the child:
   1. Set up the filesystem and network as appropriate for the given OS, maybe performing some IPC with the parent process as needed.
   2. Drop any file descriptors or elevated privileges you would not like the command to inherit.
   3. Enter the sandbox using the user-specified configuration.
   4. exec() the desired command.
3. The parent performs any IPC with the child as needed and perfoms any post-setup steps, e.g. dropping temporarily elevated privileges, if any.
4. The parent creates a Child with a PID and stdin, stdout, and stderr handles and returns that to the caller.

It would be nice to have a level of abstraction between the very high-level Sandbox builder and the very low-level os module, perhaps a trait or set of types, that would codify the general flow as defined above and enforce some behavioral consistency between backends.