Introduce an intermediate visual class

Related to #2915, #3053

Any visual related classes are expected to extend FlxSprite. This is fine in like 99% of cases, where we are working with a quad and we can inherit all its properties. However, this becomes a problem with the special case of FlxStrip.

FlxStrip extends FlxSprite, and yet does not implement most of its inherited properties, because it works in an entirely different way. As part of my rendering changes, I've been working on a replacement for FlxStrip that resolves most of its issues, like the lack of complex transformations (rotations, scale, origin...) and nonworking isOnScreen() checks.

In doing so, I've found myself in a dilemma between what class to base it off of. If I extend FlxSprite like FlxStrip did, the class would inherit a bunch of unused fields, and I wouldn't be able to even implement stuff like origin because centerOrigin() is inlined. Alternatively I thought about just basing it off of FlxObject and re-implementing the common bits but then stuff like sprite groups and anything that expects a FlxSprite would break.

I think the best solution would be to introduce some sort of intermediate class, or interface, that implements the common bits shared by both sprites and strips/meshes. That'd include stuff like angle, color (only multiplicative tinting, additive color transforms might be trickier to pull off for meshes for reasons I won't get into now), alpha, scale, origin etc...

Start by comparing FlxSprite and FlxStrip, then inspect FlxObject and the sprite-group or FlxSprite-dependent usages mentioned in the issue. Done means there is a settled intermediate class or interface covering the shared visual properties while preserving compatibility with existing sprite expectations and enabling the replacement FlxStrip design.