ModelQueryResultWrapper no longer synthesizes models for joins without FK
Oh yeah, I can see the implementation has a bad unintended consequence if the columns are aliases. Can you tell me a bit more about your use case? Its after lunch and I'm having trouble thinking abstractly. Is there an analogy example using Twitter tables? (user / tweet one to many, users to users many to many)?
 ``` python
class SMS(Model):
  sender = ForeignKey(User)

tweets = Tweet.select().join(User).join(SMS)
```

Now there should be one row for every tweet and SMS combination. Before I could get both tweets and smses from the query results:

```
tweet (unique)
tweet.user (often duplicated)
tweet.user.sms (often duplicated)
```

This isn't a great idea in practice, but we actually have a model where the `SMS` table usually only links to a `User` once.
 @coleifer have you had a chance to give this any thought yet?
 @jzelinskie -- do you work with @jakedt or has this issue arisen for you independently?
 Honestly this feels a bit like a code smell to me. The query you're executing seems very much like a hack. Why not query user and join on both tweet and SMS? Closing as this seems like an edge case that only applies to a particular kind of hack.

Due to #1012 we can no longer perform a query we were using and get reasonable results. Previously we were doing a many-to-one and then one-to-many join, and then eliminating duplicate rows on in code on the client side. In the previous behavior we ended up with a synthesized model instance for the incoming FK, and then just deduplicated those.

I know we could do this with the `<incoming_fk>_set()` method, but that would be an extra query per result row. What is the recommended way to accomplish this? We could use tuple results, but it was nice having the results parsed into objects for us automatically.
