Clean up FastStr::new_inline_impl

[saethlin]

Bug fixes and new features should include tests.

There are no tests, so I'm a bit confused by this.

Motivation

MaybeUninit::uninit().assume_init() to create a [u8; N] is UB. It is always UB, immediately, because u8 must be initialized. Code using this pattern tends to not cause issues currently because LLVM is not very good at tracking initialization, but the UB in this crate is an obstacle for assessing users of this crate.

Solution

I just used initialized bytes, as is done everywhere else. Benchmarks do not indicate any measurable performance change, which is expected for such a small buffer. The alternative is to use MaybeUninit in Repr::Inline, but that would require a lot more code change for no measurable performance impact.

I also swapped in copy_nonoverlapping; the copied ranges are guaranteed to be non-overlapping because the destination buffer is a local and the source buffer is a passed-in pointer.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[saethlin]

Oh, you have a CLA. Feel free to apply this patch yourselves. It would be nice to have.

[PureWhiteWu]

Hi, sorry for the late reply!
Thank you very much for your detailed explanation! I think you are right, although this will not cause any issue now, but it's always UB here, and the performance loss can be ignored in such a small buffer here.
I will submit a PR to fix this!

[PureWhiteWu]

Fixed in #10 .

Thanks again.