Improve beforeSave triggers for newly created objects.

[nlutsenko]

This Pull Request does a lot of things, but is setup in this way to showcase the full story on why we need these:

This fixes the following issues:

• No dirtyKeys() in beforeSave hook for newly created objects
• Crazy bug that happens due to mutation of any pointer in a beforeSave hook for the root object.

Improvements:

• We no longer attempt to run Cloud Code triggers on beforeSave hooks that were never registered, thus making it somewhat cheaper, as we don't need to create one (2 for updates) objects/decode/inflate and do magic.
• We don't inflate the full JSON for the object back for an Update, but only the changes that were applied to the object, which is explicitly inline with what we do on a v8server in Classic CC. (literally - the same function).

Changes:

• Any kind of trigger on _Session class is no longer supported, and actually shouldn't be, since it's quite scary for security, easy to mess up as well as this is not something new and it was explicitly was never supported (Parsers - D9140 for reference on the initial restriction).
• This is not a breaking change, since it was never supported in any deployment of Cloud Code, and only was supported here for less than a month (27 days to be precise at this moment).

Fixes #589

Outside of obvious improvements - here is the broader explanation on why we need to remove support for _Session, at least for now:

• We need to basically re-apply the changes to the Parse.Object to get it into the same state as people expect: dirtyKeys(), isNew() and friends.
• The only way we can do it is by using a mutating set() on a Parse.Object instance, as this is what the API allows us.
• All of this is great so far outside of a single limitation - Parse.Session explicitly catches any mutation to it's state for read-only keys. This is done to protect everyone from shooting themselves in the face and is guaranteed on all platforms.
• Since _Session class is one of the most commonly triggered operations when using Parse.User - we end up constructing it a lot of times and neither of those can actually succeed, since the setters are enforced to be read-only.
• Adding support for mutating Parse.Session via a private method is a good option, but at the same time - this exposes a security hole, since no function in JS is private.

We can plan to support triggers on sessions, but I think they shouldn't be allowed, since they introduce a lot of hidden complexity in the first place and could be a giant failure point for any application, if anything goes wrong in them.

cc @gfosco

[drew-gross]

LGTM. Re breaking changes I would consider anything that improves compatibility with Parse.com to be a non-breaking change, even if it breaks from previous versions of Parse Server.