add more semantics to API exceptions related to subsidy fulfillment

[iloveagent57]

This change helps to thread error responses from GEAG back through the response payloads of enterprise-subsidy and enterprise-access in our redemption flow.
It also sets up a more generic framework for describing, to the caller of the policy redeem endpoint, the semantics of failures that occur in the downstream redeem request of the subsidy API.
The structure of the error response will be like so (should be backwards compatible):

{'code': 'fulfillment_error',
 'detail': {'metadata': {'enterprise_administrators': [{'email': 'edx@example.com'}],
                         'subsidy_error_detail': [{'message': 'woozit '
                                                              'duplicate order '
                                                              'woohoo!'}]},
            'reason': 'duplicate_fulfillment',
            'user_message': 'A legacy fulfillment already exists for this '
                            'content.'}}

[pwnage101]

Is this just the result of the subsidy API being indecisive about error formatting and being written by >1 person?

[macdiesel]

Oof yes, can we fix the offending call?

[iloveagent57]

I wrote it to be defensive about the types of messages that can exist from a DRF APIException: https://github.com/encode/django-rest-framework/blob/master/rest_framework/exceptions.py