feat: rest of BinaryViewVector{,Mut}

[a10y]

Tracking Issue: #5028

[codecov]

Codecov Report

❌ Patch coverage is 78.13333% with 82 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.89%. Comparing base (69ef61d) to head (00bebf8).
⚠️ Report is 13 commits behind head on develop.

Files with missing lines	Patch %	Lines
vortex-vector/src/binaryview/vector_mut.rs	85.63%	27 Missing ⚠️
vortex-vector/src/binaryview/types.rs	20.00%	24 Missing ⚠️
vortex-vector/src/binaryview/vector.rs	79.04%	22 Missing ⚠️
vortex-vector/src/binaryview/view.rs	81.63%	9 Missing ⚠️

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gatesn]

If you assume the buffers are unique, then don't you just need to offset all the indices by n = self.buffers.len()?

[a10y]

But after merging the buffer points might be out of order now, so we can't just do a blanket offset.

E.g. if self has buffers [buf1, buf2] and other has buffers [buf3, buf1, buf4, buf2]

[gatesn]

I guess I assumed we just wouldn't de-dupe? As in, it doesn't really matter if other has buf1 or buf2, can just treat them as new buffers.

[a10y]

The existing builders do have some logic to try and dedupe that I figured we'd want to carry over, but if not then that certainly makes things simpler.

[a10y]

I removed the deduping logic in favor of trivial appending