Todo for a stable 0.5

[kanpov]

Expecting 0.5 to be a more complete release that is more fleshed out than 0.1-0.4. Not expecting to do 1.0 any time soon due to how complex and dynamic the crate is, leading to massive breaking changes like the 0.2 -> 0.3 or 0.3 -> 0.4 transitions.

• [x] Refine the 4 supported ownership models: shared, upgraded permanently, upgraded temporarily, downgraded
• [x] Get resource limits in jailer mapped out well
• [x] Get support for the jailer's execing in new pid ns (***)
• [x] Make VMM logs and metrics be able to be proper fifo pipes instead of files to avoid unbounded fs usage
• [ ] Un-trashing the VM shutdown implementation
• [x] Add an "either" executor that can either be jailed or unrestricted (i.e. the one from the tests with a more ergonomic API)

(***) The exec in new pid ns is particularly problematic since you can only read the PID from a file but that wouldn't get a Child handle to that process, so to do this we'd have to get blocking until PID can be read from file to work, and then either make a trait that either operates on a concrete Child or on a PID-based connection, or have both concrete Childs and connected PIDs use the same logic and drop Tokio for process management fully and just use std::process to spawn a process and get its PID immediately.

So, getting that done would be exquisitely painful.

[kanpov]

Planning to get everything except new pid ns into 0.5.0-rc.2

[kanpov]

New pid ns has been delivered at the cost of not getting the actual exit status of the process due to it being in a separate pid ns (non-child pidfd can't be used in waitid).

[kanpov]

Exit status limitation resolved with a procfs-based workaround that seems to always work, and silently falls back to assumed 0 if it doesn't.