Actually deprecate `collections::Bound`

[bstrie]

In f2c7917 , intrinsics::drop_in_place was supposedly deprecated in favor of ptr::drop_in_place:

#[rustc_deprecated(
    reason = "no longer an intrinsic - use `ptr::drop_in_place` directly",
    since = "1.18.0"
)]
pub use crate::ptr::drop_in_place;

However, this function does not show up as deprecated in the library docs (https://doc.rust-lang.org/nightly/std/intrinsics/fn.drop_in_place.html), nor does it trigger the deprecation warning in the following program:

fn main() {
    let x = &mut 42 as *mut i32;
    unsafe { core::intrinsics::drop_in_place(x); }
}

Presumably this is an unforeseen inability of #[rustc_deprecated] to operate on re-exports. Regardless it means that this function was never actually deprecated in practice, and it will need be deprecated for real with an updated since value.

This can be resolved by simply making intrinsics::drop_in_place into an actual function that merely wraps and calls ptr::drop_in_place, then and then applying #[rustc_deprecated] to it. Alternatively one could fix #[rustc_deprecated] to work when applied to re-exports, but that seems far more involved.

---

Edit: I've also discovered another example of this, which is collections::Bound:

#[rustc_deprecated(reason = "moved to `std::ops::Bound`", since = "1.26.0")]
#[doc(hidden)]
pub use crate::ops::Bound;

The problem in this case is a bit more difficult than with drop_in_place and requires a bit more care. To wit, function items aren't nominal types, so redefining intrinsics::drop_in_place as a wrapper over ptr::drop_in_place isn't a breaking change. However, redefining collections::Bound as a newtype over ops::Bound would create a new nominal type, and would be a breaking change. Furthermore, type aliases via type aren't fully at parity with "real" types, so there might be potential for breakage if one were to simply do pub type Bound = ops::Bound; (I can confirm that the #[deprecated] attribute does work on type aliases). However, I think in practice it should(?) be alright to use a type alias here (the only disparity I can think of with type aliases is that they can't be used as constructors for unit structs, but I'd like second opinions).