Add FlxG.center() and camera.center()

[richTrash21]

Closes #3309

Another attempt at #3310 based on Geokureli's suggestion

Adds FlxG.center() and camera.center() for centering sprites by their graphic size and FlxG.centerHitbox() and camera.centerHitbox() for centering objects by their hitbox size.

[NeeEoo]

I'm not really sure if reflection in c++ works when using generics.

Because both FlxG.random.shuffle and FlxG.random.getObject both don't exist in reflection due to generics

[richTrash21]

I'm not really sure if reflection in c++ works when using generics.

Because both FlxG.random.shuffle and FlxG.random.getObject both don't exist in reflection due to generics

As far as i know the reason why FlxG.random.shuffle and FlxG.random.getObject doesn't exist in reflection is due to @:generic metadata.

I've also made a small test to confirm that:

class Main {
	static function main() {
		var stringField:String;
		var intField:Int;
		var floatField:Float;

		stringField = test1("some string");
		intField = test1(30);
		floatField = test1(1.0034);

		stringField = test2("some string");
		intField = test2(30);
		floatField = test2(1.0034);

		trace(Reflect.getProperty(Main, "test1")); // returns test1 function
		trace(Reflect.getProperty(Main, "test2")); // returns null
	}

	static function test1<T>(v:T):T {
		trace("test generic func #1 (" + Std.string(v) + ")");
		return v;
	}

	@:generic
	static function test2<T>(v:T):T {
		trace("test generic func #2 (" + Std.string(v) + ")");
		return v;
	}
}

[NeeEoo]

Damn, i wonder why haxe wouldn't generate a base one for reflection purposes

[Geokureli]

Note that the actual graphic width of a sprite depends on sprite.getGraphicBounds and sprite.getGraphicMidpoint(), which is the world coordinates of the graphic, and accounts for origin, angle, offset, pixelPerfectPosition and any future features or features in extending classes.

Also note: there is sprite.getScreenBounds, which accounts for scrollFactor and camera.zoom

We should use those (and be sure to put any rect/point back into the pool), or if you think it's beneficial we can add a sprite.getScreenMidpoint()

I thought about maybe having getGraphicWidth, getScreenWidth and the like, and having the existing methods use that, but truthfully, it might be a hassle, and even a little less performant. I'm leaning against that, but let me know what you think