Restructure the features client/api resource to reflect the separation of feature domain models

[asorici]

the task involves making each individual feature instance (e.g. a given program or order feature attached to a location) accessible by a clean URL reference. We will consider the suggestions from
https://restful-api-design.readthedocs.org/en/latest/intro.html and http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api.

Amongst other things this task involves:

• splitting up the client/api module into submodules that create the specific
  resources for the corresponding model of a feature domain (e.g. for the program
  feature domain we will have the Session, Presentation and Speaker resources);
  these resources should be accessible under a URL similar to
  .../features/programs/10/sessions/1,
  .../features/programs/10/sessions/1/presentations/2,
  .../features/programs/10/speakers/3, etc
• creating an actions sub-collection for each resource which servers as an entry-
  point for non-REST conforming actions (the ones that are more complex or have
  side-effects) - e.g. searching, request for profile matching, etc

[asorici]

I restructured the way in which we build the API entry point for each feature.
For example the program feature is now accessible at: ../features/programs/...
while annotations for program presentations are accessible at: ../annotations/program_ann/...
Also, each feature domain model and resource are now contained within the same feature folder in the application project. This makes code containment and isolation clearer.

For the moment, I have not further pursued the idea of creating a Resource for each feature domain model, nor the idea of creating resource nesting for these models.
The thing is that Django-Tastypie's support for nested resources is somewhat non-mature. Also, the efforts to try and automate feature domain resource creation and nesting for an equivalent feature domain model, as well as to change the client side to the new API, currently outweigh the benefits they bring to the application.

Under the current application model, an "actions" sub-collection for each resource can be added when needed.