neon: drop the align requirement on vld1/vst1/vld1 lane loads and stores, dup loads

[valentynkit]

vld1/vst1 lane functions and vld1 dup functions were de-referencing pointer directly which requires it to be aligned to the element type. (Too strict alignment requirements)
The instructions don't requires alignment, so calling these with unaligned pointer caused UB.

Lane loads and stores, and dup loads were updated to use read_unaligned() and
write_unaligned() instead.

Use crate::ptr::read_unaligned(ptr) instead of ptr.read_unaligned() because the same convention is used in neighboring code. Let me know if the other approach seems cleaner and should be used instead.

Also on armv7 the 64-bit loads now compile to vld1.8 instead of vldr (vldr requires an aligned address), so their arm assert_instr values updated to match. Without this the tests would fail after getting rid of alignment requirements in the function, and the f32 lane and dup loads LLVM emits ldr + vmov/vdup.32 on arm instead of a NEON load form, so those four asserts now expect ldr. Is this acceptable, or I am missing something here, it feels pretty unreliable to change assertions, but not sure if there are a better way?

Align requirement documented in:
ARMv7-A and ARMv7-R Manual ch A3.2.1

This covers a bit more than the reported issue required to fix it, but there look to be more places with the same category of bug, because implementation requiring stricter alignment that instructions do.
I could take a look at those as follow-ups, if it will be valuable.

Fixes #2198

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @sayantn (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn
• @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn expanded to Amanieu, adamgemmell, davidtwco, folkertdev, sayantn
• Random selection from Amanieu, adamgemmell, davidtwco, folkertdev, sayantn