api wrapper modules improvement

Currently most API modules in Horizon (openstack_dashboard/api/*) are sets of module methods, e.g. when working with Keystone, I can call methods like:
flavor_list (for getting list of lavors)
keypair_create (for creating new keypair)
...

This is the only layer between Horizon views and service libs (e.g. novaclient). So I see these modules as a layer that adapts service lib interface for calls I do from django views. E.g. if I update a user, this layer takes care of different API version behaviour and calls one or more API methods (and anything else that is needed, important is that I use only this single update user call from my app).

It would be nice to improve these modules:
- wrap module methods into classes that would mostly represent API resources - Tenant, User, Keypair
- these classes would implement basic (CRUD) operations and additional business logic related to these resources
- if a method returns an object, it would return object of this class or other class defined in openstack_dashboard/api/ modules (e.g. flavor_get would return instance of Flavor class which inherits from APIResourceWrapper) instead of an instance of an entity from the underlying client lib.

E.g. for flavor methods defined in openstack_dashboard/api/nova.py, the class might look like this: https://gist.github.com/jprovaznik/5793088
All of this is already used in various openstack_dasboard/api modules, but not consistently.

Major benefits:
- cleaner organization
- it would be always clear what value I get when I call a method
- well defined place where I can put a business logic related to the resource
- better version compatibility handling - if an API call behaviour is changed between v1 and v2 you can just define new class for v2 that inherits from basic resource class and overrides methods that are now different (instead of having if-else version check in each of these methods)