Use JSON API errors

We would like to return more useful, consistent, structured data to
clients. Testing out this approach for dashboards, as discussed.
Allow PUTs containing modules to work correctly

When putting a list of modules, if they include an id, then update the
module with data from the PUT request.

Not yet implemented removing module as it is a separate story, but have
added a skipped test for this functionality
Switch to data_group and data_type in get response

Avoid exposing the data_set id in the api, as it is a numeric field
rather than a uuid, and we use data_group and data_type for creating
modules, and never require the id.
Add page-type to list of dashboards

Spotlight needs this, and we should ensure it’s part of the published
schema.
Update transaction links rather than creating

If the link is of type transaction, update the link rather than creating
a new one

This could be handled by passing a link_id to the link_data, but as the
admin app currently only support transaction_links and not other links
we have gone with this solution
Update test to not rely on factory boy sequence

Although there is still only 1 link in the db, factory-boy has used the
sequence link-2 instead of link-1 - if we are explicitly testing for
values on objects we shouldnt rely on the factory boy generation - its
more useful for not having to specify values that are not to be tested.
Allow posting empty module id

This is to avoid doing a lookup on an empty key, which results in a
server error, and is to follow the "be liberal in what you accept"
principle.
This rescues when the module type id is not set in the request.
Accept either slug or UUID to return dashboard resources

- A bit fugly in the views because we're doing stuff like `is_uuid(identifier)`
- Allows us to do e.g. `/dashboard/{uuid}` and `/dashboard/{slug}`
- Could do with a refactor but I think that can probably be bundled up with https://www.pivotaltracker.com/story/show/78992766