[WIP] Hitbox refactor

[cspotcode]

Implementing some of the ideas from #1568

So far, what I have is incomplete, but it shows that we can skip a ton of hash remove/add operations for sprite movements, when those movements don't change the sprite's hash. This makes hashing viable for very dynamic sprites.

Initial benchmark results

Sorry these results are hard to read.

Without this optimization, adding spatial hashing to the moving bullets slows it down. Compare rows 2 and 4 to see this.
But with this optimization, adding spatial hashing to the moving bullets gets much faster. Compare rows 1 and 3 to see this.

With spatial hashing of moving bullets

Command	Mean [s]	Min [s]	Max [s]	Relative
95d85e2e WIP optimize spatial hash updates so that sprite is only added/removed when necessary	16.206 ± 0.717	15.699	16.713	1.00
d2f267a4 update benchmark, add variant that hashes the bullets	33.140 ± 1.306	32.217	34.064	2.04 ± 0.12

Without spatial hashing of moving bullets

Command	Mean [s]	Min [s]	Max [s]	Relative
95d85e2e WIP optimize spatial hash updates so that sprite is only added/removed when necessary	21.312 ± 0.589	20.895	21.728	1.00 ± 0.03
d2f267a4 update benchmark, add variant that hashes the bullets	21.237 ± 0.014	21.227	21.247	1.00

TODOs

• refactor _hit_box_max_dimension to be a tuple describing the max extent of the hitbox along each axis
• benchmark with https://github.com/pythonarcade/arcade/blob/development/arcade/examples/performance_statistics.py
• avoid unnecessary set() creations in setdefault calls in hash traversal

[Cleptomania]

Through much conversation and work on discord. We have landed on the API introduced with #1641 which serves the purpose of giving us a more pluggable HitBox API that we can accelerate via Rust.

Thanks @cspotcode for the input on this system as we've built it out more.