datastore: commit transactions after queueing modifications

### Do not merge

- [ ] Unit test `commit`
- [ ] Confirm docs build correctly

RE: #300

With this PR, Transaction overrides `save` and `delete`. It wraps the underlying methods, `DatastoreRequest.save` and `DatastoreRequest.delete`, so that we can track what entities are going to be queued for modification when the `done()` callback from a transaction is executed.

As decided in #300, the last modification wins. There are two regression tests that confirm this behavior with a delete before a save and a save before a delete to confirm they are handled properly.

This also makes a big change to how `.save` works. Currently, the callback provided to `save` will receive the same keys it passed in, with any incomplete keys now being made complete. I never found this very practical, as keeping track of the index of my key when I pass it in to then access it again from the callback is unnecessary when I could instead just have one Key object reference that is automatically updated for me.

```js
// Previously

var completeKey = dataset.key(['Company', 'Google']);
var incompleteKey = dataset.key('Company');

dataset.save([
  { key: completeKey, data: {} },
  { key: incompleteKey, data: {} }
], function (err, keys) {
  keys[0] === completeKey // true
  keys[1] === incompleteKey // false
});

// With this PR

dataset.save([
  { key: completeKey, data: {} },
  { key: incompleteKey, data: {} }
], function (err) {
  // incompleteKey has now been given a path with an ID
});
```

As always, (well, most of the time), I tried to leave comments where things could be hard to follow. Even still, if I failed to make things understandable, please just let me know and I will try to correct that.
Kinda sucks I can no longer do something like this because in this case, the original key object is lost and no longer returned. Is there some way we can still return the keys AND update the original keys?