Model sync() performed after 'saved' event, so isDirty() can be used properly

_**Taylor Otwell**: Honestly the original way kind of makes sense to me? After a model is saved it shouldn't be "dirty" anymore._ #4139

When a model is saved, it should not be considered dirty any more - _as far as the general flow of code is concerned_. Of course, a model cannot be perpetually dirty after it's saved, that just doesn't make sense. It needs to be cleaned/synced at some point.

However, this should be done _after_ the 'saved' event, which is when we're broadcasting that a save has taken place, so that listeners are able to enquire and test what has changed. It's quite reasonable to expect certain listeners to only want to listen for particular types of changes.

Consider the current scenario of events:
 * **Model**: Hey, I just got saved ('saved' event fired)
 * **Listener**: Oh? What got changed? (event listener that may only want to act if particular fields got updated)
 * **Model**: Oh... nothing changed (as the model isn't dirty)

How frustrating is that??

Or lets imagine the conversation another way
 * **Model**: Hey, I got saved again ('saved' event fired)
 * **Listener**: Hmm, what changed now? (event listener trying to check)
 * **Model**: Errr, I can't tell you... (again, model has been cleaned prematurely)

Again, that just helps no-one.

With this change, the conversation is:
 * **Model**: I just got saved ('saved' event fired)
 * **Listener**: What changed? (listener checking for changes)
 * **Model**: Well, field A is now $foo, field B was unchanged, and field C is $bar (model::isDirty() works)
 * **Listener**: Wonderful, thank you. I'm going to do something because field C changed to $bar (listener is happy)
 * **Model**: Cool, now I'm going to set myself clean (sync event fired, from this point forth the model is now clean)

Once the event has been fired and processed, the model isn't dirty any more.

All this boils down to is allowing listeners listening for the 'saved' event to be able to test for what has changed, and I see no reason to hide that from them. It's counter-intuitive, and it's of no benefit for the event listeners to receive a clean object over a dirty one, because if they didn't care about the change, they can retrieve the current values anyway. The current method just penalises listeners looking for a 'saved' event, and forces them to duplicate code by creating a 'created' event handler (which will receive a clean object), and an 'updated' event handler which *does* get passed a dirty object (which itself is an inconsistency in the code - it should follow the same rule of saved - either both 'saved' and 'updated' get dirty objects, or both get clean ones - it's non intuitive for one to receive dirty and one to receive clean when they're the same type of action).

Apologies for the long explanation, but as this is a retargetted version of #4139, which was closed after Taylor's comment, I don't my response was read so I wanted to resubmit and establish my case again properly for 4.2. Thanks