Remove redundent information and optimize dynamic allocations in Table

[Adamkob12]

Objective

• fix Table redundantly stores 3 lengths and capacities for each column #12853
• Make Table::allocate faster

Solution

The PR consists of multiple steps:

1. For the component data: create a new data-structure that's similar to BlobVec but doesn't store len & capacity inside of it: "BlobArray" (name suggestions welcome)
2. For the Tick data: create a new data-structure that's similar to ThinSlicePtr but supports dynamic reallocation: "ThinArrayPtr" (name suggestions welcome)
3. Create a new data-structure that's very similar to Column that doesn't store len & capacity inside of it: "ThinColumn"
4. Adjust the Table implementation to use ThinColumn instead of Column

The result is that only one set of len & capacity is stored in Table, in Table::entities

Notes Regarding Performance

Apart from shaving off some excess memory in Table, the changes have also brought noteworthy performance improvements:
The previous implementation relied on Vec::reserve & BlobVec::reserve, but that redundantly repeated the same if statement (capacity == len). Now that check could be made at the Table level because the capacity and length of all the columns are synchronized; saving N branches per allocation. The result is a respectable performance improvement per every Table::reserve (and subsequently Table::allocate) call.

I'm hesitant to give exact numbers because I don't have a lot of experience in profiling and benchmarking, but these are the results I got so far:

add_remove_big/table benchmark after the implementation:

add_remove_big/table benchmark in main branch (measured in comparison to the implementation):

add_remove_very_big/table benchmark after the implementation:

add_remove_very_big/table benchmark in main branch (measured in comparison to the implementation):

cc @james7132 to verify

---

Changelog

• New data-structure that's similar to BlobVec but doesn't store len & capacity inside of it: BlobArray
• New data-structure that's similar to ThinSlicePtr but supports dynamic allocation:ThinArrayPtr
• New data-structure that's very similar to Column that doesn't store len & capacity inside of it: ThinColumn
• Adjust the Table implementation to use ThinColumn instead of Column
• New benchmark: add_remove_very_big to benchmark the performance of spawning a lot of entities with a lot of components (15) each

Migration Guide

Table now uses ThinColumn instead of Column. That means that methods that previously returned Column, will now return ThinColumn instead.

ThinColumn has a much more limited and low-level API, but you can still achieve the same things in ThinColumn as you did in Column. For example, instead of calling Column::get_added_tick, you'd call ThinColumn::get_added_ticks_slice and index it to get the specific added tick.

[james7132]

Please fix CI, looks like clippy still has the last word, haha. Great job getting this to pass miri!

Only a partial review. Will finish later.

[Adamkob12]

looks like a segfault in run-examples-macos-metal ci? needs investigation
e: fixed

[vertesians]

For the component data: create a new data-structure that's similar to BlobVec but doesn't store len & capacity inside of it: "BlobArray" (name suggestions welcome) (This type makes a compile-time destinction between ZST types and non-ZST types)

I like UntrackedBlobVec for this concept -- "thin" in Rust contexts typically refers to pointer sizes, but the data structures aren't pointers. And IMO, "untracked" is clearer about the intention. By the same logic, I like UntrackedVec and UntrackedColumn over ThinArrayPtr and ThinColumn (assuming ThinArrayPtr is implemented like a Vec).

[james7132]

We may want to follow this up with a PR for applying ThinColumn for both resources and sparse sets.

[james-j-obrien]

Changes look good to me, it's a lot of code but most of it is fairly straightforward and mirrors the other container implementations pretty closely.

I've left some nitpicks that I don't see as blocking, feel free to ignore them.

[james-j-obrien]

Why remove the getters/setters?
The fields are private so it's not a big deal, but we lose the ability to annotate safety and so won't get clippy lints encouraging safety comments when people touch the fields.

[james7132]

The primary thing is that they're dead code. They're no longer used in any form as these types are entirely internal. We'd need to add some allow(dead_code) annotations.

[james7132]

Due to the amount of unsafe in this PR, merging now is a potential risk for 0.14, moving this to merge early on in the 0.15 cycle.