Optimistic `block` endpoints

This PR adds two new endpoints: /bookables/createBlocks and /bookables/deleteBlocks

`POST /bookables/createBlocks`

This endpoint takes a list of start-end ranges and creates blocked timeslots. The body of the request is following:

{
  "marketplaceId": <uuid>,
  "refId": <uuid>,
  "blocks": [
    {
      "start": "2016-12-05T08:40:20.438Z",
      "end": "2016-12-05T08:40:20.438Z"
    },
    { ... },
    { ... }
  ]
}

The result is a 201 status and the body content is an array of newly created blocks:

{
  "data": [
    {
      "id": "string",
      "type": "string",
      "attributes": {
        "start": "2016-12-05T08:40:20.464Z",
        "end": "2016-12-05T08:40:20.464Z"
      },
      "relationships": {}
    },
    { ... },
    { ... }
  ],
  "meta": {},
  "included": [
    {
      "id": "string",
      "type": "string",
      "attributes": {},
      "relationships": {}
    }
  ]
}

Status 404 is returned if a bookable can't be found with marketplaceId / refId pair.

`POST /bookables/deleteBlocks`

This endpoint takes a list of block IDs and deletes those blocks. The body of the request is following:

{
  "marketplaceId": <uuid>,
  "refId": <uuid>,
  "blocks": [
    { "id": <uuid> },
    { ... },
    { ... }
  ]
}

The result is a 201 status and the body content is an array of deleted blocks:

{
  "data": [
    {
      "id": "string",
      "type": "string",
      "attributes": {
        "start": "2016-12-05T08:40:20.464Z",
        "end": "2016-12-05T08:40:20.464Z"
      },
      "relationships": {}
    },
    { ... },
    { ... }
  ],
  "meta": {},
  "included": [
    {
      "id": "string",
      "type": "string",
      "attributes": {},
      "relationships": {}
    }
  ]
}

Status 404 is returned if a bookable can't be found with marketplaceId / refId pair.

Todos / open questions

Questions:

[x] Is the 201 correct status for deleteBlocks endpoint?
[x] Is the body format correct?
[x] Is the response format correct?
[x] Should the deleteBlocks HTTP verb be DELETE?

Next PR:

[ ] Ensure we don't add blocks for booked dates. This will be done in the next PR. Thus this PR is "optimistic"
[ ] Silently ignore double blocks (i.e. timeslots that have been blocked already). This will be done in the next PR.
[ ] Move create/delete blocks tests away from timeslot tests. Add dedicated tests for them, possibly using property based testing. And test all corner-cases, such as double blocking and blocking booked dates. This will be done in the next PR.
[ ] Do we need to ensure each block is 1 day?

sharetribe / harmony