feat: added string-store

[kyranet]

TODO

• Write remaining tests
• Write examples in README
• Write documentation
• Handle edge cases
  • Invalid offset (writing outside buffer length)
  • Invalid offset (reading outside buffer length)
  • Invalid fixed-length array input (not an array, mismatching length)

[kyranet]

This PR has been rewritten from the ground up, all reviews from the previous implementation are stale.

stale

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[favna]

Also needs updating:

• .github/labels-yml

1. Is there a way to add a whole object so new Schema(Id) is valid somehow? It's a bit weird to be adding Obj.key for every single key IMHO

2. Few people will know what all of int2/4/8/16/32 etc mean, especially those who don't know C-based languages. I count myself among them in fact. Please describe them better.

[kyranet]

.github/labels-yml already contained that label, and did so since db64a22

Is there a way to add a whole object so new Schema(Id) is valid somehow? It's a bit weird to be adding Obj.key for every single key IMHO

I chose the chainable method since it's a builder in builders, but Zod/Shapeshift-like objects can be done in a follow-up PR, this version is good enough as-is.

Few people will know what all of int2/4/8/16/32 etc mean, especially those who don't know C-based languages. I count myself among them in fact. Please describe them better.

int2 and int4 don't exist in any language (to my knowledge), they make sense in string-store because the unaligned buffer storage makes it take less space than an aligned one (which would store both as an int8 at minimum).

That aside, I wrote some more documentation, I hope that explains it.

---

By the way, after landing this PR, I'd like to hold off the v1.0.0 release, I want a first version in so I can work on QoL and details without having them around a massive PR, that way they're easier to review and to iterate.