RFC: Remove aligned-vec dependency

[FreezyLemon]

Motivation:

• DIY version is small (<200 LoC vs 1500). normally not a big deal but there is a very high amount of unsafe code in the crate
• crate seems to be passively maintained (two issues regarding UB have been open for a while without response)¹
• slims down dependency tree a bit

Footnotes

1. cases of UB should not concern v_frame ↩

[codecov]

Codecov Report

❌ Patch coverage is 95.45455% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.48%. Comparing base (f629ccb) to head (d53a34f).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/plane/aligned.rs	95.23%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
+ Coverage   94.27%   94.48%   +0.20%     
==========================================
  Files           3        4       +1     
  Lines         332      453     +121     
==========================================
+ Hits          313      428     +115     
- Misses         19       25       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[FreezyLemon]

Of course the performance regresses now... let me investigate.

[FreezyLemon]

Okay, ready now. If we include #52 then there is no performance regression on my machine. byte_data seems a fair bit quicker but still comparatively slow, might be worth investigating afterwards.

As a bonus, AlignedData allows access to uninitialized data in a UB-free manner through MaybeUninit, if we want to expose this through the public API later.

[shssoichiro]

I wonder if we can make a specialized impl for T: Copy that uses copy_nonoverlapping (or copy_from_slice) instead. Should be even faster if your other PR is any indication.

[FreezyLemon]

Speed seems to be about the same on my machine for a Plane::clone() vs a plane.copy_from_slice(&data) from the benches. Roughly 35-40 microseconds, so I think the compiler already catches it in this case.

[shssoichiro]

It seems to not be guaranteed. There may just not be any places using it in a performance critical way in this crate. Nevertheless since I'm already testing it, I may as well push up a specialization for it.

Iterator method generates a loop:

.LBB3_5:
	movzx edx, byte ptr [r14 + rcx]
	mov byte ptr [rax + rcx], dl
	inc rcx
	cmp rbx, rcx
	jne .LBB3_5
	jmp .LBB3_6
.LBB3_1:
	mov eax, 1

copy_nonoverlapping generating a memcpy:

.LBB3_1:
	mov edi, 1
.LBB3_4:
	mov rsi, r14
	mov rdx, rbx
	mov r14, rdi
	call qword ptr [rip + memcpy@GOTPCREL]

[shssoichiro]

Apparently specialization is still not stable. WTF Rust it's been like 8 years.

[FreezyLemon]

I thought you had some neat trick up your sleeve 🥲
I think specialization is still some time away too.. would've been nice to have, but oh well