LDPSerializer dependent on view and request

There are several points in the LDPSerializer code where it relies on the Request and View objects in the context. This prevents us from being able to use it outside of strict boundaries

Permissions

One reason why the request/view are accessed is during the serializing of permissions, which invariably require the view/request for context. This could be refactored by passing the permissions into the serializer during construction, if they are missing then don't serialize them (#299 (closed) , #277 )

Serializer cache

The cache is varied on the user. I think that the cache could probably also be bypassed when no request is present - leaving it up to the developer to make their own performance improvements

Resolving ID

• many_init uses the request path to resolve the container's urlid. Perhaps here we could pass in the urlid as a parameter or use a Blank node if none is present
• Rest Framework's HyperlinkedField uses the request to resolve the ID. We often use the urlid of the instance and I'm not sure that we would want to inherit the behaviour that generates one, since it duplicates the urlid-generation logic

Resolving parent_model in LDListMixin

Needs further research

With the changes suggested in #277 it may be that the LDPModelSerializer (or a variation of it) has to become coupled to the view in this way, but it should be totally possible to decouple at least the LDPSerializer from this, which should be possible to use freely as it is in DRF