Expand ThinBox API to support fallible allocation

[tleibert]

Proposal

Problem statement

ThinBox can only be allocated with the standard allocator API model, where any errors encountered while allocating are handled by calling the global handler. This behavior is not desirable in environments where manual error handling is needed, even for memory allocation errors.

Motivation, use-cases

One of the motivating uses for ThinBox is passing trait objects or other DST's over an FFI boundary.
The main example I have for why we'd want this is closed-source (for now).
In my recent work with the FreeBSD kernel, I implemented the ability to use closures as callback functions/event handlers for kernel processes. However, passing them over the FFI boundary required a double-box:

let ffi_safe_box: Box<Box<dyn FnOnce(...)>> = ...;

This was required to overcome the fact that the inner box is a wide pointer, which isn't able to be safely passed to C without another layer of indirection.

ThinBox already solves this issue, but it is unusable in this project as any allocation errors will trigger a panic, and inside the kernel, a panic means the kernel itself panics and the whole system goes down.

Solution sketches

ThinBox::try_new mimics Box::try_new, and simply bubbles up any errors encountered during creation as core::alloc::AllocErrors. The function is implemented nearly identically to how the original is.

Links and related work

[Pending Open Source Release of FreeBSD kernel work]

[the8472]

My general "too many allocation API variants" concern applies here, elaborated in rust-lang/wg-allocators#90

[dtolnay]

Adding unstable ThinBox::try_new sounds good to me, as long as we wouldn't stabilize it before figuring out whether to keep Box::try_new which is currently unstable too.