fixes to DELETE method handling

 * the if-block for deleting an object from a relation was not committing; the tests were still passing because the session was still open and the next API call would pull the object out of the session, not the DB. Put a `session.remove()` before the API call to check that the removed object is actually gone from the relation, and you'll see that it's still there in the DB.
 * Idempotency only means that subsequent identical requests cannot have
additional side-effects. Since the response code is not a side effect,
but rather a return value, `DELETE` should respond with `204` only if
an object is deleted, and with `404` when nothing is deleted.
  (It is very confusing if an API returns `204` to a DELETE for a nonexistent
or inaccessible resource.)