Added model states to encapsulate operation behavior dependent on state

Added two states to the Note model - Locked state and Unlocked state

  Locked State - The model becomes unmodifiable. Modifiable views are
  hidden and modifiable views are shown.

  Unlocked State - The model becomes modifiable. Unmodifiable views are
  hidden and modifiable views are shown.

Summary of how states are managed:

  States are changed through the controller (the activity classes) via
  the setMessageState() method. The current state is stored in a
  dedicated controller property - noteState. References to activities
  are passed to the state classes themselves, during construction of
  state objects, so that the state classes can change the note state if
  necessary. In the current implementation, state classes provide toggle
  methods since there are only two possible states. These toggle methods
  use the activity reference to change state when necessary.

In-depth explanation of the State System:

  - Views - each state is associated with two views. The Unlocked state
    is associated with a title EditText and a body EditText. The Locked
    state is associated with a title TextView and a body WebView. The
    views for the unlocked state allow for user input, whereas the views
    for the locked state do not allow for user input.

    Views are hidden and shown based on the current state of the note
    model. Whenever the note model state is changed, the View checks
    what the updated state of the note model is, and hides/shows the
    appropriate views (this is done via the bind() method in
    NoteView.java). The bind() method is invoked by the Event subsystem.

    The WebView allows pinch zooming without the interference of UI Zoom
    controls. This works by disabling UI Zoom Controls whenever the user
    is pinch zooming.

  - State System - provides a polymorphic system for defining different
    method behavior based on the current state at the time of method
    invocation.

    An interface defines methods that must be implemented across all
    states. These methods are called, regardless of the current state
    referenced in the controller.

    A class (NotationState) implements the interface and provides an
    opportunity to define methods that will be the same for all states.
    For example, in the current implementation, the constructor will
    always be used to store references to the controller and model,
    which will be accessible to all state objects. This class also
    allows for the defining of default implementations for the interface
    methods.

    Finally, state-specific classes extend the NotationState class and
    provide state-specific behaviors for the interface-declared methods.

    This whole system allows the declaration of a ControllerState
    property (ControllerState is the state interface) in the Controller
    which will then be able to hold a reference to ANY state object and
    invoke the interface-declared methods; the actual behavior of the
    methods will depend entirely on which state object being pointed to
    by the ControllerState property!

    Another thing to note - upon construction of state objects, a
    reference to the Controller is passed to the state object. This
    allows state objects to use the setMessageState() method as
    described in the next section.

  - Controller - contains a property dedicated to storing a reference to
    a state object; this object is considered the current state

    The controller contains a local NoteView.ViewListener object which
    defines what to do as a response to a View event (clicking the
    top-middle toggle button). The View event handler delegates
    responsibility to the Controller. The View class itself has no
    knowledge of what the controller is doing, it simply invokes the
    controller event method whenever the View event (clicking the
    button) occurs. From there, the controller can update views, models
    or whatever as necessary if the View event needs to trigger such
    changes. In our implementation, we simply update the model state by
    toggling the noteState lock.

    The controller also defines a method for changing the current state,
    setMessageState(). This method changes what the noteState property
    points to, and thus, changes the state. This should called
    immediately after any model change to ensure consistency between the
    actual model object and the state object the Controller noteState
    property is pointing to.

  - Model - The model contains the entire Event subsystem.

    The View class defines EventListener objects. These objects define
    what operations need to take place whenever a Model event occurs.
    The Model contains a ChangeEvent inner class which defines constants
    that act as ids for all possible Model events. The View class
    associates each ChangeEvent ID with an EventListener object and
    registers these associations with the Model.

    Now, whenever a property in the model is modified, the appropriate
    ChangeEvent ID will be passed to the Event subsystem. The Event
    subsystem will then invoke the appropriate EventListener object.

Signed-off-by: Byron Sanchez <bfs5030@gmail.com>