Possibility of exposing `RcBox` for transferring allocations between `Box` and `Rc`

The idea occasionally comes up of whether Rc could take ownership of a Box and re-use the allocation, or conversely of converting a uniquely-owned Rc into a Box. While logically intuitive, this runs up against the physical limitation that Rc stores the reference counts inline in the allocation, ahead of the data, and so the two would not be compatible as-is. Making Rc store the reference counts out of line in a separate allocation (like std::shared_ptr) doesn't seem to be worth the overhead just to support this case.

If, however, we were to consider the ability to avoid some allocations in this way important enough, we do have a fairly straightforward option available to us to support it in some cases: publicly expose the RcBox type which comprises an Rc allocation (without necessarily providing access to the internal RcBox of any Rc - just the type). Something like this:

#[derive(Copy, Clone)]
pub struct RcBox<T: ?Sized> {
    strong: Cell<usize>, // private
    weak:   Cell<usize>, // private
    pub value: T
}

impl<T> RcBox<T> {
    pub fn new(value: T) -> RcBox<T> { ... }
}

impl<T: ?Sized> Rc<T> {
    pub fn from_box(source: Box<RcBox<T>>) -> Rc<T> { ... }
}

pub fn try_into_box<T: ?Sized>(self: Rc<T>) -> Result<Box<RcBox<T>>, Rc<T>> { ... }

(By keeping the reference count fields private, we can ensure that the reference count of any RcBox not currently inside of an Rc is always 1, so that from_box doesn't even need to check or reset them.)

Start by reviewing the proposed public RcBox type and the ownership and allocation-layout constraints described in the issue. Assess whether exposing RcBox, from_box, and try_into_box provides enough value to justify the API and safety implications; done requires a resolved design decision rather than a small isolated edit.