Consider separating concepts of screen from camera

Presently, FlxCamera represents both the position at which a world is being observed (FlxCamera.scroll x/y) and the rectangular screen on which the world is drawn. It might be worth considering splitting these up, having both a FlxScreen and FlxCamera.

The obvious drawback is that it adds a little more complexity, although in practice most of this complexity would be hidden.

Benefits would include:-

• Easily swap cameras while maintaining screen size and position, as cameras are simply attached to a screen.
• View the same camera from different screens.
• Camera position would actually be the camera position (more intuitive than having a "scroll" position
• Encourage better implementations of existing features such as shake and zoom, which currently manipulate the entire screen position and size, whereas it would be better to implement these in terms of the screens view of the world.

I think most stuff you already do with FlxG.camera(s) would stay the same. There would need to be some way of tracking the screens, though.

Additional considerations:-

• Screen would have to be responsible for actually using some properties of the camera, such as the cameras bounds, as the effect is dependent on the size of the screen.
• Attach multiple cameras to the same screen? Possibly useful for HUD layers?

Start by reviewing FlxCamera, its scroll x/y state, and the FlxG.camera(s) usage mentioned in the issue. Trace how camera size, position, bounds, shake, and zoom are currently handled, then establish an agreed design for FlxScreen/FlxCamera responsibilities and the behavior that would define completion.