Adopt DRF exceptions and define error codes for API responses

[giohappy]

At the moment the many APIs (DRFs for API v2 and the legacy Django views) implement their own way to return errors. This is problematic for many reasons, including a nonstandard and harmonized way for the client app to handle errors.

To overcome this we want to implement a common response schema, to be adopted both by GeoNode's DRF APis and, if required, by any legacy Django views APIs that are still used by the new client and that cannot be ported to DRF right away.

DRF already provides a clean approach based on the generic APIException class, which is automatically converted to a formatted Response by the default exception_handler. Every DRF API should employ this approach, which means raising an exception instead of returning a Response directly. The available built-in DRF exceptions will be adopted for generic errors, or APIExceptions with custom codes will be raised for specific errors.

It will be important to define the custom error codes as constants or enumerations so that they can be reused in multiple locations if required, and they can be used for documenting the APIs (e.g. through drf_spectacular's extend_schema decorator, which is already partially adopted).

If we still have Django view APIs for which it is worth to implement the same response interface, a custom Response class can be implemented with the same schema as the one generated by the DRF exception_handler