Support for URI references to resources

I've modified to code to allow a Resource to supply a uri_prefix.  If it
does, then references to those resources will no longer be simple
object ids, but completely URIs constructed from the uri_prefix and
the object id.

There is one remaining issue in this code which is that I haven't handled
all cases where related_resources is used.
This makes sure all field are properly serialized

When serializing fields in an object, check to see if they have a uri_prefix
and an id attr.  If so, serialize them as URIs
Forgot a change to construct proper URIs

The Location header allows us to return the URI of the object created by
the POST request.  However, it doesn't include the network location portion
(hostname, port, etc).  That gets added by flask/werkzeug at some point.
So all we need to do is make sure we have the proper path at this point.
Forgot a condition

We need to check to make sure that the resource type actually defines
a uri_prefix before we attempt to do this.
Fixed a bug that caused tests to fail.

I had one lingering issue which showed up when I ran the nose tests.
That issue is fixed and now all the original tests that were written
for the flask_mongorest package pass in the context of my changes.

My one remaining task is to write some additional tests that test
my additions.
Added a test for new POST behavior and fixed on last bug

I had one last case where I had a variable name wrong.  I also modified
the example application to introduce a uri_prefix for one of the resources
and then tested that a successful post to create that resource
returned the resource location in the Location header of the
response.  Furthermore, I made sure that the resulting URL contained
the uri_prefix associated with that resource.
So close...

There appears to be an issue in the tests where a URL for a resource is
passed into the API and the JSON response that is returned from the
POST request shows that the URL for the field has changed.  It looks like
perhaps a **copy** of the resource referenced via the URL is being made.
Exercising much more of my changes and tests are back to passing
Added a utility method that generates URIs for a given Resource

One issue I have found is that the normal convention for REST interfaces
is that a URL ending in "/" normally represents a collection of resources
whereas a URL ending with no "/" represents an individual resource.

In terms of passing URIs for resources, we need to be consistent and I've
followed the convention above.

The problem is that the test cases don't really honor this convention.
As a result, there are many requests formulated in the test cases that
would simply lead to a 301 (redirect) status code.  So I set the
`app.url_map.strict_slashes` flag to be false which seems to cause
werkzeug to avoid the redirect and just respond directly to the request.

All of these changes are backward compatible with respect to any code
that pre-dates the existence of the `uri_prefix` in `Resource`.
Damn, forgot to get rid of some print statements
Explicitly specifying the complete URL for resource Location in POSTS

Instead of relying on Werkzeug or Flask to 'complete' the URL
from the URI reference currently provided, this explicitly specifies
the complete URL.  This is laying the foundation for returning
complete URLs in other places as well.
Fields are not returned from API as full URLs

I modified the code so that instead of returning URI references, a
full URL is now returned from the API.  This makes it consistent
with what is returned in the Location header during a POST request.
Extension to specify per-request resource types

This is useful when you have a view to a Document that allows
inheritance because it can use request information to determine
exactly what type of resource is being POSTed or PUT.
Got rid of self.assertIn

I noticed from the Travis builds that this is not compatible with
Python 2.6 so I switched back to the alternative way of making these
assertions.
Added some authorization methods

These methods map exactly to the way Django does things.  The only thing
we are really missing is the "read" permission.  However, that part is
tricky because it interacts with the QuerySet objects.  For that reason,
I left it out (upt to this point) to focus on the ones that were pretty
straightforward.

This includes some extensive tests for these permissions checks.
Added support for read permissions.

The read permission is different than the other permissions because
it has to hook into the QuerySet system.  I implemented this in such
a way that the `has_read_permission` method is given a QuerySet and
returns a QuerySet of objects that the given request should have
read access to.  The default behavior is, of course, to just return
the initial QuerySet.

I added a test for this behavior as well.
Trying to add some documentations so others can follow what I did here

Tried to add comments and docstrings to explain what was going on in
this set of commits.
Cloning QuerySets

I didn't notice before that the QuerySet objects have internal state.
I assumed that each time you applied a filter, a new QuerySet object
was created, but this isn't the case.  So when calling has_read_permission
it is necessary to clone the queryset to avoid side-effects.
Merge pull request #25 from xogeny/requested_resource

Extension to specify per-request resource types
Print more descriptive error message if posting an incorrect Content-Type; Closes #28