Update API's forbidden view config to not always return 404s

At present, `h.views.api.exceptions` defines a `@forbidden_view_config` (i.e. handler for 403 responses) for use by API endpoints. However, this view always changes `request.response.status_code` to `404`—de facto changing the response to an `HTTPNotFound`.

In some cases, this is what we _should_ do, so as not to leak information about whether a protected resource—which can be identified by part of the request path—exists or not. But in other cases, a `404` is misleading and kind of wrong. An example is `POST /api/groups`. That should return a 403 if auth fails, not a 404.

There are a couple of ways to approach "fixing" this; the obvious mechanism being a view predicate that can apply a different handler depending on the context (sometimes a 404, sometimes a 403). There are some patterns in the routes and traversal that may be useful "hooks" for determining when to do what.

_Note_: The default/main forbidden view handler—not just the API's—does this always-return-a-404 thing as well. This issue pertains to the API variant.