Moving frame (or view) implemented to follow ship

This commit implements an early version of a focused
camera. This way, a large picture can be loaded as the
background, and the much smaller resolution frame will
adjust to keep the ship in focus. Everything still
renders to a surface, only what is shown is adjusted.
Future improvements in efficiency can change this to
only blit or render what is visible to the focused
ship.
Shift backgrounds at different rates

The lowest background (black w/ stars
in the example background layers) now
shifts at a fraction of the speed of
the other backgrounds, giving the sense
of perspective.
Increased stack size

Trying to load a massive bkg
resulted in seg fault. Attemped
to fix this by increasing the stack
limit of the program. This however
does not seem to fix the issue; the
program continues to seg fault on a
call to SDL_DisplayFormatAlpha().
Cleaned up main; Added config CLI option

Removed the code that makes the old CLI
options relevant. However, the old scanning
code is left as future reference; will probably
allow config option overrides via the CLI. This
will come later as its needed.
Start of primitives support; cleaning up

Basic primitive support has bgeun, but is
by no means done. Procedural generations of
things like lines, circles, and boxes will be
provided for ease of use. Otherwise, this
commit contains a bit of code clean up.
Began PixMap implementations

Very first exploration of mapping
the sprites as they are loaded.
Exploring the potential of per-pixel
hit detection using such maps.
Cleaning up some unused variables
More cleanup and small refinements

Organizing and prepping for some big changes
Code cleanup

Removed a few obsolete, no longer used
methods from Game and RuPPAT.
Added pixel removal to Sprite class

This is the first step to deformation,
destruction, and general manipulation
of sprites in realtime. It takes a bit
of geometry to allow the engine to
avoid re-rotating a newly deformed
base sprite. Instead, the manipulated
pixels of the base rotation can be
transformed and applied to each rotation.
This should be a much faster process than
altering the base sprite and then parsing
the rotations again using rotozoom.
Initial decoupling of Physics from objects

All gravitational physics depends on Object
class in a more refined way. Objects can be
"acted on" by a source, but they can also
"act on" a destination. This can be used in
the future to decrease loop iterations. It
also permits Pixels and Objects to be handled
nearly the same; the base struct of the pixel
(Entity_desc) is used for its physics now.

The Physics handler in Object is a virtual
function, allowing it to be overidden when it's
derived, thus different Classes (player, weapon,
etc.) derived from Object can behave completely
differently with regards to physics (this will be
the method of implementation for other things, such
as collisions).
Lots of backend changes; Missiles emergin

To better facilitate expansion of the object
class and its derived classes, quite a few
changes have been made. Most importantly,
the physics is now handled by the Object objects
themselves. In fact, these PhysicsHandler functions
are Virtual, allowing them to be easily overidden
in the derived classes. This also allows for simple
execution of the handler function; inherent in the
virtual function standard is the execution of the
most derived version of the function for that object
of any base/derivation level. Very useful.

Now, the Player class, derived from the Object class,
overides the physics handler to include calculations
for any launched Missiles. Which bring us to the next
major addition: *Missiles*. Any object-like weapon,
affected by physics and collidable, should be based
on Missile. The Player class is now composed of a
vector of missiles and fire missiles. The object takes
care of updating the missile once it has been launched.
Using the space bar now files the "White Rocket", which
means it does nothing more than spawn it and let it sit.
Though it is affected by gravity. A few things to clean
up still (alpha seems to be broken on the missile sprite)
but the concept is there.

Quite a few additions were made to help this along,
mainly implementing rule-of-3 things on the Sprite
class to allow better data movement. Also, the
PhysFuncs has now been separated out into prototypes
and definitions as it is being included into far too
many classes for a simple definition to suffice. The
PhysFunction namespace is quite a mess at the moment,
but that should change once the Missiles are better
implemented and my focuses shifts to physics revamping
and collision detection.
Fixed minor Missile bug; Added orange blob

Fixed a minor bug with the Missile demo implementation,
where the x coordinate value was being assigned to both
x and y of the new missile. Also, added an orange blob
sprite as a place holder for the missile, this way
early development of collision detection and rotational
physics can be simplified for the meantime.
Missiles fire with velocity with aim

A few more features to the Missile; the missile now
fires out from the player's ship in the direction the
ship is pointing. A few functions were added to Object
to make this a bit easier, and support it for future
derivations from Object.
Fixed mouse follow

Mouse follow has been borken since the
screen centering on player feature was
implemented. Simply needed to shift the
mouses x and y values by the origin of
the screen (or camera). So that ability
is back now (Left Ctrl will turn ship to
the mouse).
Removed valgrind error output text file

File called valErr removed.