Add a way to override the execution order of certain class-level and method-level response handlers

[prkumar]

Is your feature request related to a problem? Please describe.
Here's the original question raised by @liiight on gitter:

so i have a class response handler to handle request errors, which basically just does raise_for_status()
I have another response handler that I want to use in order to retry 404 status code via a retry lib I use
I set the 2nd response handler directly on the relevant method but it seems that the 1st one is the one that actually catches the exception
is there a way to decide on the order of those?

Describe the solution you'd like
There should be a way to specify that a particular method-level response handler should run before any or certain class-level handlers.

Additional context
Here's my response to the original question:

currently, class-level decorators run before method-level decorators, as you noticed in your usage. #72 (v0.4.1) details some of the rationale for this. Currently, Uplink doesn't give you a way to decide on the order between class-level and method-level decorators. From what I can tell, there are two existing workarounds, but both have drawbacks. First, you could make the retry response handler a class-level decorator. If you don't want all methods to be retried, the other workaround is to apply the raise_for_status decorator on each method, but this makes things more verbose.

[cognifloyd]

Here's my use-case for this feature:
I have a class level annotation that raises errors when status >= 400. But, I just discovered that one of the APIs also returns 404 when it should be returning an empty list, so I want to check for 404 in a method-level annotation before the class-level 400+ check happens.
This is the ugly handler that I wanted to apply to only one method (while still allowing it to be covered by the class level handler). Instead, I had to move the class level handler down and decorate every method with it since class level runs before method level.

@response_handler
def returns_empty_list_on_404(response):
    # ugly hack to handle stupid api
    if response.status_code == 404:
        response.status_code = 200
        response._content = '[]'
    return response