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.
The original key object would be lost, but to cater to a use case that is illogical (unless I just haven't considered something) doesn't make sense to me. I can't see anyone storing the index of a key they intend to be completed, then accessing that offset from a later-returned array. With less effort, all they have to do is store the key outside of the argument passed to save. If a user doesn't store a reference to a key they are passing to save, that tells me they won't intend to use it again. And more generally, if a user doesn't store a reference to *anything*, that also tells me they don't intend to use it again.

Worth noting, in either case, the API call will still succeed.