Refactor: DRY model spec code

The model spec contained some repetition: some spies were created
repeatedly. We removed that repetition by using the beforeEach
so-called "hook" function provided by Jasmine.

More importantly, we completely decoupled examples from each other by
forcing new blank instances of our model to be created within them.
This suppresses all risks of cascading failing tests.

What we learned:
* Hooks in Jasmine
* "DRY" principle (and how to not abuse it in tests)
* "Independant tests" principle: don't share state between tests
Refactor: Turn view into instantiatable constructor

Similarly to what we did to the model, we turned the view into a self-
contained instantiatable object.
Refactor: Turn controller into instantiatable constructor

The controller is the latest component we had to turn into an object.
The view and model instances are injected into the controller, making
all those objects highly decoupled.

What we learned:
* Injecting dependencies into constructors
* Accessing properties of an object instances from itself
* Injecting doubles to isolate an object during tests
Refactor: Move user action handling to view

The view is now responsible for catching user interactions with the UI
(i.e. clicks on cells). The controller - which is responsible for
orchestrating things between the view and the model - registers a
listener to the view. The listener is executed by the view to notify
the controller the player is shooting at a cell. The controllers then
tells the domain (via our model) to handle that event.

The controller (application layer) is now simply listening to some
events on the user interface (presentation) and delegating it to the
model (domain).

What we learned:
* Presentation, application and domain logic separation
* Registering a simple callback
Refactor: Decouple acceptance tests (work in progress)

Each test *should* be independant. Even acceptance tests. We expect
the system under test to be in a clean blank state when a test is
starting to reduce risks of flickering and to ensure the deterministic
nature of our tests.

In order to reach that situation, we start a new game before every
single end-to-end tests.

What we learned:
* All tests should be independent
* Tests start with a system in a clean (or very well-known) state
Problem: Dual-state cell in the grid during tests

When hitting, the cell is marked as both a hit and a miss. Try to
understand why and fix it if you can!
Solution: Introduce templates

The problem we faced proviously lies within the DOM. Event though new
instances of all our objects (view, model, controller) were properly
created before each example, the DOM table and cells was not changed.

Previously attached event handlers were still being triggered. This
means our previous game, view and controller instances were reacting
to clicks on the cells, as well as the newests. In short, the same
TD elements were being tight to different instances of the game.

To avoid that incorrect behaviour, we've introduced the concept of
templates, which brings other interesting benefits to our application.
They will help organize the HTML into smaller reusable units that are
bound to views.

What we learned:
* How listening to events affect (unreferenced) object instances
* How careful we must be with listeners
* The concept of view templates and how to define/use them
Update README from commit history

Generated using the following command:

`git log --format="## %s%n%n%b%n[View this
commit](https://github.com/mattwynne/js-testing-training/commit/%H)%n"
--reverse > README.md`