Default camera width to 320x240 and default to joystick

Most webcams allow for a resolution to be set at 320x240, so it
makes sense for the defaults to be bumped slightly to meet this.
In the future, this should be configurable, similar to how it is
done in the Cheese photo capture application.

The default controller has also been changed to the joystick.  While
the other controller works as expected, the boundaries of the image
are set to the boundaries for the image, requiring the user's face
to fill the entire webcam.  The joystick controller does not
require this, as it works relative to the original calibrated point.
Tweak the joystick a little

When the camera loses the location of the nose, it previously
stopped moving the cursor.  Considering this is a joystick, and we
calculate the direction of the cursor constantly, we can assume the
user is still planning on moving in the last calculated direction.

This also moves the cursor relative to its position on the screen
instead of relative to the last calculated location.  This allows
the cursor to be manually moved if needed, and it will still work
as expected without jumping the cursor to the last location.
Added very basic click support

This is essentially a spike implementation of a left-eye based
click support.  This will allow users to fire a mouse click if the
mouse is not moving and the left eye is detected as closed for 1.5
seconds.  There must be an 80% success rate for detecting that the
eye is closed.  This will only fire a single click event for each
time that the eye is determined to be closed.

Many of the values here, such as the eye scale and minimum
neighbors, as well as the success rate were arbitrarily chosen and
can be freely tweaked to better values.
Add logging.
Remove Makefile.am from src/ (for now).

We are not ready to implement autotools stuff. Our code base is
changing too rapidly. When it settles down, we'll implement it.
Pointers now return a list of ScreenPointerEvents which gui.ScreenPointer interprets.
New core architecture.

main.py had too many reasons to change. It was responsible
for instantiating all system components and passing messages
between compoents. So, anytime a new component was added or
a change in there interaction was desired, main.py had to
be changed in non-trivial ways.

main.py needs to provide a stable, predictable platform on
which to build new features.

New classes

    mousetrap.main.App
    mousetrap.main.Loop
    mousetrap.main.Observable
    mousetrap.main.parts.interface.Part

App - Provides shared state among Parts eliminating the need
      for Main to pass messages between Parts.

Loop - Drives the application calling run() on each Part each
       pass of the loop. It is the observable in an observer
       pattern with Parts as observers. Use of the observer
       pattern means that Loop does not need to know the
       details of each specific Part.

Observable - Provides implementation of observable in the
             observer pattern.

Part - The interface each part must implement.

To implement a new Part:

1. Implement the Part (e.g., see mosuetrap.parts.eyes).
2. Add part description to DEFAULT_PARTS in main.py.

This second step will go away when DEFAULT_PARTS is
converted to a configuration file in a future commit.
Move logging into log.py.
Main is gone.
Parts are now identified by fully qualified class name.
Merge pull request #14 from GNOME-MouseTrap/stoney2

New architecture
Rename `Part` to `Plugin`.
Removed backup file

I'm guessing this was a backup file, either way it shouldn't exist
here in git.
Might as well use Python casing for the logger
Don't fire clicks if the mouse is moving
Remove negation from function/method name.

(Kevin, this is not directed at you; this is just me rationalizing
why I don't like negations in function names. Surprisingly, I
found only one "article" on the subject:
http://programmers.stackexchange.com/questions/196830/boolean-method-naming-affirmative-vs-negative .
Maybe I need to put this on my blog.)

I'm not a fan of negations in function/method names that return
boolean values.

1. They set the stage for double negatives at the call site which
   is difficult to read.

    ```
    if not self._not_moving():       # is it moving or not? ouch!
    ```

2. They make the body of the method harder to interpret because
   returning True is really returning False (or is it?).

3. Affirmatives are good for the soul! :)

Existing functions with negations in their name can be fixed in two ways:

1. Think of another name that describes what the function is testing.

    ```
    _not_moving  -->  _stationary
    ```

2. Rewrite the function to test for the opposite and remove not from
   the name.

    ```
    _not_moving  -->  _moving
    ```
Rename _history to _eye_detection_history.
Simplify eyes.py

* LeftEyeLocator.locate() now returns a boolean instead of raising an exception.
* _eye_detection_history now stores booleans instead of None and locations.
Introduced History class to manage length of histories.
Removing extra call to pointer.get_location() and moving updating
of pointer history next to updating eye detection history.