Refactoring tick-management out into a separate class

I wonder if I might be going overboard with all my little
state-management mini-classes, but I suspect that I'm probably not.
`World` is currently a hulking behemoth of unrelated nonsense, and that
ought to change.
Correcting some classes' constructors

Oy.  Seems that I misunderstood how part of the CoffeeScript language
works.  To think that I thought I knew every significant thing I would
need to know....

As it turns out, initializations that happen outside of the
constructor are static initializations--basically, set once, when the
prototype is first created.  Modifications to those statically-
initialized values after the fact are inherited by all other
objects that instantiate the class.  Confused?  Here's how I ran into
the issue:

```
class World
  _turtles: []
  constructor: ->
```

`World` doesn't set `_turtles` in its constructor; only in the
prototype.  So... I run a test, which creates a `Workspace`, which
creates a `World`, and I put some things into `_turtles`.  Then, I go to
run the next test, get a **newly-created** `Workspace` and
`World`, and check the `_turtles` value.  Turns out that my new `World`
still has all of the turtles that the old `World` had!

You might say, "Wait, how did we not run into this before?"  Well...
because it's tricky.  See the answer [here](http://stackoverflow.com/questions/8355371/coffeescript-class-members).
Basically, this value is defined at the prototype level.  All things
that extend the prototype inherit the value.  So... you change the
**value**, meaning that you change what everything inherits.  But, if
you change the **reference**--if you put something new into that
prototype variable instead of modifying the value inside of the
variable--no one else inherits that change.  Extends continue to get
that original reference, whatever its current value is.

So here's my new policy:

  * All prototype-level variables are declared as `undefined`
  * All class variables are to be **listed** at the prototype level
    or as arguments to the constructor
  * All class variables are to be given their proper initialization
    values *within* the constructor
    * If you think you're initializing a class variable outside of the
      constructor, you're wrong, because there's no such thing--not
      consistently, in the way that you're probably thinking.

If these guidelines are followed, I think that classes will have clear
manifests of what their variables are, and they'll always be initialized
to the predictable values.