Refactor transition-group to use per-element state machines

[nonphoto]

WIP

This PR is an effort to resolve Issue #466 by taking the best of both worlds from transition-group and presence

As mentioned in #466 presence primarily works by deriving element appearance from transition state. However, it is missing:

1. Modes: parallel and in-out
2. Callbacks for animation completion (instead of duration-based timeout)
3. List transitions

In opposition, transition-group works by attaching callbacks to elements that have already rendered. It is lacking:

1. Access to transition state from within the transitioning item's context
2. The ability to run different animations per transitioning element.

This PR resolves these differences by introducing the TransitionItemContext type, an instance of which holds the transition state for each element in a list. createListTransition now returns an array of tuples: [T, TransitionItemContext]. The user can use TransitionItemContext to register transition events or track the transition state independently for each element.

Currently only createListTransition has been modified. If this PR goes over well I will extend the functionality to createTransition as well.

---

This also has the added benefit of removing from jank from the playground's transitions.

Old:

https://github.com/solidjs-community/solid-primitives/assets/3441123/9fa290a1-4ec0-4afe-ab2d-321ebbd19bae

New:

https://github.com/solidjs-community/solid-primitives/assets/3441123/d3081081-7c7d-4c2e-a2eb-c995d7a3a98a