Remove unsafe from array_ref! macro

[nabilwadih]

unsafe is no longer needed here since this is now supported in stable rust, the panic behavior is the same as before since it would panic anyways if the slice index was out of bounds

[burdges]

Anyone cleaver regression tests done yet?

If it's slower in niche cases, then maybe one should've a no_unsafe default feature doing this, so then basically everyone benefits but in theory someone who notices a regression could revert to the unsafe form. Just fyi, you can also prove unsafe code correct, ala the rustbelt project, which becomes basically as good as not having unsafe code.

[nabilwadih]

@burdges thanks for the suggestion! I wrote a simple benchmark here: https://github.com/nabilwadih/arrayref/pull/1/files (open to suggestions on anything else you would like to see benchmarked)
And based on the results, there seems to be no difference in performance of the implementation without unsafe:

Based on that, I don't think it makes sense to add a no_unsafe default feature flag

[ejpcmac]

It seems removing the unsafe block has quite a big impact in term of size: on a thumv8m.main-none-eabihf target, I’m getting 128 bytes of additional usage per use of the macro when trying the code from this PR.

I’ve come to discover this wonderful crate because I was trying to find a way to split an array of u8 to u32 so I can feed them into registers, and found the conventional copy_from_slice or try_into methods that we see advertised everywhere introduce quite a big size penalty. I’ve been able to reduce the code size of a lib by ~10% just by using arrayref, so I’d be in favor to add a feature flag to keep the same size performance (maybe it could be non-default, so that only people needing an extra size optimisation would enable it).