In testing this PR, I noticed that `$doc->a` is still set due to the previous query. I originally expected that it might revert to `null`. This is due to behavior in [`UnitOfWork::getOrCreateDocument()`](https://github.com/doctrine/mongodb-odm/blob/9828ad004fcbd37f0bd7bb5ade98ec40c3bb7f55/lib/Doctrine/ODM/MongoDB/UnitOfWork.php#L2771), where the refresh hint used by Query and Cursor (a) causes the new data to be hydrated atop the existing, managed document and then (b) reverts the document's original data (for changeset calculation) to the data that was just hydrated. In the case of this test, we lose `a` from the original data after this refresh.

I'll note that this query/cursor refresh hint is nothing like `UnitOfWork::refresh()`, which causes the entire document to be reloaded from the database. That's simply unfortunate, as I think users could easily mix them up.

So, since this refresh hint resets the document's "original data", I think it would be ideal if it created a fresh document instead of hydrating some new subset of the data atop the existing document; however, that would mean other instances of the document would no longer be managed and users would need to manually merge them back into the document manager.

This really isn't a problem specific to the PR, but the fact that it is an issue gives me pause to silently introducing a refresh hint if the user is performing a projection in their query. For that reason, I think it'd be best if they explicitly called `refresh()` and acknowledged the above behavior on their own. I'd be interested in any thoughts you might have on the above, too.

/cc @jwage