datastore: scope Key creation to include NS. fixes #116.

RE: #116

I actually have 2 different implementations for this, but this was the one I thought was the most logical.

When a user creates a dataset, they can provide a namespace. Then, anytime they need a key, instead of `datastore.key()`, they call `datasetInstance.key()` - the key will be created with the namespace already bound to the Key.

The other implementation removed any association of a namespace from a Key object, which [felt wrong](https://developers.google.com/datastore/docs/apis/v1beta2/key).

PTAL & LMKWYT.
I worded my analogy wrong. It's really more like this:

> "When defining a variable that is meant to later hold an object, it is advisable to initialize the variable to null as opposed to anything else. That way, you can explicitly check for the value null to determine if the variable has been filled with an object reference at a later time"
> \- [Nick Zakas](http://stackoverflow.com/questions/6604749/what-reason-is-there-to-use-null-instead-of-undefined-in-javascript)

Where we expect a string, if one isn't provided, we cast it to undefined, as we didn't receive the string we expected. The significance is what the value provided to the Query constructor means in the context of a Query. If it's null, undefined, empty string, 0, or anything that's not a legitimate string value, it means "undefined", user didn't define a namespace. Inside the Query.prototype methods, we're simple casting to a boolean, so any of the above will work the same.

In the end, there really is no reason to use null vs undefined vs 0 vs false (etc etc) in a case like this, except for convention and preference. I prefer to stick to the convention, but will happily go null if you wish. :+1: