Added EndFlush event

This was mentioned on Twitter, this is just a POC to further the discussion.

**Updated 10-05-2014**

The flush terminate event would be fired *after* the flush has finished *only* when there are pending changes. 

My primary use case is to enable enitities to be persisted recursively after the initial flush.

The existing `endFlush` event is fired before the UOW is cleaned up, i.e. whilst the UOW is still dirty.

### Use cases

* Recursively persisting documents

### Example problem

For example, we flush an `Article` entity. 

* There is a listener which must create a `Route` entity automatically
  for the `Article` entity.
* There is a listener which must create a `Version` entity for each `Route`.

In the first listener would listen to the `onFlush` event, check the changesets for any `Article`
enitities, create a new `Route` entity and recompute the changeset. The new `Route` entity would
then be committed in one flush.

There is however no sensible way to implement the second listener - if we were to 
implement it in `onFlush` we would have to be sure that the listener was called *after* the first listener.

This "order of precendence" problem doesn't scale.

### With the `terminateFlush` event.

* The `Article` entity would be persisted
* User calls `flush()`
* An `RouteEventSubscriber` subscriber listens to the `onFlush` event and tracks any `Route` objects which are due to be persisted.
* The UOW completes the transaction, and the flush has finished.
* The `flushTerminate` event would be fired
* The `RouteEventSubscriber` checks to see if any `Route` objects have been persisted, if so it creates a new `Route` object, perists
  it, and calls flush again.

The same process now take place with a `VersionEventSubscriber`.

So in summary, when an Article is comitted, 3 flushes take place and three enitities are persisted.

### Transactions

I think that any additional flushes should *not* be part of the same transaction.