fix delete from relation

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.
return 404 for DELETEs to nonexistent/inaccessible resources

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.)
allow disabling deep results per-request

originally by @johaness
allow fine grained control of relations included in output
bump to 1.current-upstream-version
support deep parameter in PUT/PATCH

follow up to d85b91e0d5d133ddb989d31ce98ae4f385d2432f and dc06ae4ae75994d354db8bbe62532bd04da0b5ac
search: joined load of all deep relations
limit joins to 3 levels
bump version number to Major.minor.revision.2
Raise exception for bad searches

... so that we can register an error handler in Flask to show
helpful response messages to API consumers
Support Python 3.3
bump version number to Major.minor.revision.3
Reraise `deep`-related json parsing exceptions as BadRequest
bump version number to Major.minor.revision.4