Use sparse entity-to-node mapping for ContactGraph

[Jondolf]

Objective

The ContactGraph maintains an entity-to-node mapping using a custom EntityDataIndex. This is similar to the Coarena in Rapier or SecondaryMap in slotmap.

This works fine for physics entities. However, the structure's keys are the indices of the vector itself, which means that space is allocated for every entity from index 0 to the largest physics Èntity index. If you had a million non-physics entities, and one collider spawned later, it would also allocate space for those million non-physics entities.

Solution

Replace EntityDataIndex with a similar SparseSecondaryEntityMap, backed by a HashMap rather than a Vec. This is modeled after the SparseSecondaryMap in slotmap.

This does most likely make random access slightly slower, but reduces memory usage.

Alternative: ColliderId

We could keep the current data structure, but maintain collider IDs that are separate from Entity IDs.. This would let us only allocate for physics entities.

However, we would then need to maintain an Entity-to-ColliderId mapping (or query for ColliderId) at least to make the public API less painful. So, a sparse mapping is required regardless.

We can explore this option later to see if it would be any faster, but for simplicity, I would prefer to keep using Entity directly, and so only have the sparse mapping.

[Jondolf]

Also noticed that this is unused in 3D

[Jondolf]

Using Entity IDs is actually also a problem for the SpatialQueryPipeline, so I'm looking into adding separate collider IDs and reworking this stuff further.

[Jondolf]

Or I'll actually merge this now and handle the SpatialQueryPipeline separately.