More classes to represent other resources from the API (User, Installation, Push)

First of all, thank you for the work on the library you already had. It worked as a great starting point for me in the work I'm doing that requires integration with Parse.

The first change was the inclusion of a setup.py file, in order to make this module pip-installable.

Next, I've made a few additions to the library, and it would be great if we could turn this module into a complete client library. There are some changes in the naming of classes, and I understand that this can break some code you have. However, there are no changes in how these classes behave, and a simple search/replace should work.

If you take a look at the pull request, you will find that I took your ParseObject and ParseQuery classes and applied the same design to implement other classes that have resources exposed through the REST API. I have a Django app that needs to expose an API of its own to a mobile app that is already using Parse, so I need to be able to get information about users, authenticate them, do some operations on behalf of the client, etc... so you will find most of that functionality on the "User" class. I also need to do Push notifications, so I also implemented the Push and Installation classes.

On this refactoring, I moved some of the functionality from ParseObject to a base class called ParseResource, from which all resources (Object, User, Installation, Push) now inherit. Everything related to the HTTP calls are now part of ParseBase.

The same idea is done in ParseQuery. It has become a base class (called Query), which can be used for querying and filtering of users (UserQuery) and installations (InstallationQuery), querying for ParseObjects can be done by using ObjectQuery.

I haven't add any tests, but I made sure that none of the tests you had are broken. I'm planning to add more tests soon.

Lastly (and not related to this pull) I wonder if it's possible to change the license of the code - from GPL to a BSD/MIT-derivative. None of my current projects are going to be redistributed, but it might be the case that some developers won't adopt this module due to the viral clause of the GPL.

Thank you,
Raphael Lullis