Enhancement (DELETE) and Bug fixes (around POST response)

1. In fetch(), the check for negative response to raise HALNavigatorError,
       if raise_exc and not self.response:
            raise HALNavigatorError(self.response.text,
                                    status=self.status,
                                    nav=self,
                                    response=self.response,
            )    
   Is not too late in the flow?. I feel it should be checked before processing the response body 

2. PostResponse can have properties, hence implemented __call__ to return properties

3. DELETE method is similar to POST from Navigator perspective (non-idempotent) 
  Hence,
         a) Reused logic from POST to implement support for DELETE
         b) renamed PostResponse to HALResponse 
         c) renamed  create() to post() for clarity
   In order to provide backward compatibility, I created alias "create"  to "post"

4. HALNavigator should not allow POST if the uri is templated. The check for templated_uri 
   was missing. Created a wrapper function (@template_uri_check) to re-use for all methods - GET/POST/DELETE

TODO:
1. Enforce templated_uri check for all HTTP calls. Add test coverage 
2. a link usually have 'method' property (default to 'GET'), which can be used to restrict http operations. this helps to raise NotImplementedError and can have a controlled default function e.g autofetch
I think part of the ethos of rest_navigator is that it makes it natural to use things the right way, but lets you do things the wrong way if you want, you'll just have to work harder or the code might be uglier. We don't hide anywhere that `create` is doing a POST request underneath, so if you're wondering "how do I do a post?" you look at the docs and find it pretty quickly. Then, when you go write the code, if you find yourself calling `create` and you aren't really creating something, you'll feel weird and wonder if you're doing something wrong, which is good.

There's a point to be made that the consumer of the api doesn't have any control over this, but I think most people who are consumers of HAL apis (right now at least) are also the creators, so it makes sense to create some friction here when the api isn't using methods quite correctly.