Expand FlxObject colliders

Obviously a huge endeavor, but I think I have a way to implement this with backwards compatibility. Putting in 6.0.0 for now, but it's likely to get pushed back.

FlxCollider

This can either be an enum, or done with inheritance. but the basic types (for now) would be:

• Rect/AABB (x, y, w, h): Similar to the existing collider, but the main difference is that the shape can be placed relative to the sprite's x and y. Previously you would use sprite.x ,y, width and height to define the collider and use offset.x/y to align the graphic to the hit shape. this contradicts what most devs intuit. Now you can use x and y to set the top-left of the collider relative to the object's x/y (you can also still use offset, for backwards compat, or for any reason you want)
• Circle (x, y, r): I've worked out circle-circle collision using FlxQuadTrees in a jam game, so it's almost ready, we need some non rect shape just to show that other shapes are possible, but we don't need to launch this with a huge polygonal collision library. a circle (and all shapes) will still have a width and height, which is used for quadtree partitioning
• Custom: Maybe the base shape with overridable methods for detecting and resolving overlaps. by default if a shape doesn't have a case for a specific shape, it will call that shape's detect and resolve methods, so we'll need to prevent infinite loops of them passing path and forth

FlxObjects

With this change, FlxObjects will just be FlxBasics with a position and a collider. for backwards compatibility, we can make obj.width a getter for obj.collider.width, this should prevent confusion between a sprite's graphic size and collision size. In the long run, I want flixel to have more of a decoration pattern, where instead of FlxObjects and FlxSprites, there are just FlxBasics with collider and graphic components.

Note to self: width and height are so integral to so many people's proprietary systems that they cannot even be deprecated for a while. not until graphic width and collider width are less conflated

Start by reading the existing FlxObject and FlxBasic responsibilities, then review the FlxQuadTrees collision approach mentioned in the issue. The proposed work spans collider types, collision detection and resolution, and backwards-compatible width and height behavior; the scope and completion criteria need to be narrowed before implementation.