Consider replacing `BoxNewUninitSlice::new_uninit_slice` with a free function

[kupiakos]

warning: an associated function with this name may be added to the standard library in the future
 --> src/extension_traits/boxed.rs:266:19
  |
8 |  let mut values = Box::<[u32]>::new_uninit_slice(3);
  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
  = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
  = help: call with fully qualified syntax `new_uninit_slice(...)` to keep using the current method
  = note: `#[warn(unstable_name_collisions)]` on by default

warning: a method with this name may be added to the standard library in the future
  --> src/extension_traits/boxed.rs:274:13
   |
16 |      values.assume_init()
   |             ^^^^^^^^^^^
   |
   = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
   = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
   = help: call with fully qualified syntax `assume_init(...)` to keep using the current method

[danielhenrymantilla]

So, FWIW, this collision was intentional insofar it's polyfilling what Rust ought to be providing, and this way users will get an automatic upgrade whenever the stdlib APIs become available (be it through enabling the corresponing feature()s or by them being stabilized); that being said, I admit this may not be to everyone's liking, so we can indeed add equivalent free functions for them (but I'd still like to keep the current APIs)