Real change events through state

Started as work on #264, where we wanted to notify the user when he has to save. For that we need to know when a real change has happened. Many future plugins are dependent on this as well - history and user tracking is not possible without it. 

Up until know we had no real chance to do that, as plugins just changed their objects in place without anyone knowing about it. Adding watches for that would not only have been ugly, but also very performance-expensive.

We therefore introduce `state.change`, along with `state.watch`.

Both come with fairly comprehensive specs, so check them out for their exact syntax. `state.change` is probably the way to go to declare state changes, that could be shared with others (history, user tracking, distributor service to other clients), explicitly. It's important to go through this function, as it produces a special `StateChange` object, which is timestamped, knows about old and new value and about ways to undo itself (hooks are present to define a pre-execution function - i.e. before the new value is set - and a custom undo function, which is probably mostly useful when a pre-exec function was needed.

`state.change` also distributes this `StateChange` object in a `tokenChange` event. Plugins can listen to this event directly through `state.on('tokenChange')` (which is equivalent to `$rootScope.$on('tokenChange')`) or much more efficiently through `state.watch`, a notification service, which somehow mimicks angular's `$watch`. `StateChange` includes the token property that was changed, such as `head.id` - `state.watch` makes use of this to allow plugins to listen to specific token changes only such as `state.watch('head.id')`. This way the plugin would only be notified when the head id changes, but not when e.g. a relation label was updated.

Navigator and saver make use of such events to allow for more reasonable saving. We only update chunks were changes were made and only enable the function to save when there is something to change.


#143 is almost covered, we close it for now and deal with the rest later. History is basically working. Morphology, heads and token adding/removal works. The dependencyTree watches need to be updated, as well as the `nestedMenu` directive, which is responsible for changes through the `relation` and the `SG` plugin. This directive needs probably a general overhaul - this might be a good oppurtunity to do so, therefore we exclude work on this from this Pull Request.

The `history` plugins uses two other additions to `state`: `silent` mode and `batchChange` mode. Silence is used to give plugins a chance to skip specific events. The history e.g. doesn't want to listen to a change that has been initialized by itself through an undo. Batch changes appear when multiple changes should be taken as a single operation that can be undone/redone, such as connecting several tokens to a new head at once.

This is also unit tested, use the specs for further reference.

There are other areas that need more work: Once we add more than one persister, some problematic things will be uncovered, but we'll come to that soon.


Closes #264 

Closes #143