Previously has_object_permission defaulted to returning True when
unimplemented because it was assumed that has_permission had already returned
true, but when composed with OR, this might not be the case. Take for example
the case where you want an object to be accessible by the user that created it
or any admin. If you have a permission IsOwner that implements
has_object_permission and IsAdminUser which doesn't, then if you OR them
together an have a user that is neither the owner nor the admin they should
get denied but instead IsOwner will pass has_permission and IsAdminUser will
pass has_object_permission even though it didn't pass has_permission.

One solution would be to default has_object_permission to calling
has_permission but that would potentially cause redundant database lookups.
Alternatively this could be done only in the OR class, but the redundant
calls will still happen.

Also, incorrect behavior can still occur using more complicated compositions
including NOT. For example, the IsOwner permission above only implemented
has_object_permission and not has_permission, but ~IsOwner will always fail,
even on objects that the authenticated user doesn't own, because the default
True from BasePermission.has_permission() will also be inverted.

My solution is to be more explicit about when a permission subclass doesn't
implement has_permission or has_object_permission by returning NotImplemented.
NotImplemented is truthy in a boolean context, so by default everything will
continue to work the same as long as code is not expecting the result to
literally be True or False. I modified AND and OR so that if one side returns
NotImplemented, it defers to the other. If both sides return NotImplemented,
NotImplmented will be returned to propogate upwards. NOT will also propagate
NotImplmented instead of inverting it. If NotImplemented propagates
all the way up to APIView.check_permissions or
APIView.check_object_permissions, it is considered a pass (truthy).

The previous test ensured that a permission whose has_permission returned
False but didn't implement has_object_permission didn't cause an OR to
suceed regardless of other conditions. However, if a permission doesn't
implement has_object_permission but has_permission returns True, that should
count as having permission on all objects.

…rmission

Composing permissions with OR should fall back on has_permission when
has_object_permission isn't implemented. If has_object_permission is
not implemented, than its has_permission should apply to all objects.
Strictly speaking, BasePermission.has_object_permission could return
self.has_permission(request, view), but only in the OR case is it possible
that wasn't already true, so only doing that fallback in the OR case
saves some redundant calls to has_permission.

Handling permissions with OR is tricky. If a permission only implements
has_object_permission, we wanted has_permission to return NotImplemented
instead of True, so that inverting it does what you would expect
(invert the object-level logic, don't invert the default has_permission True
so the object-level logic is never checked). However, having OR ignore
NotImplemented means that if the thing it is ORed with returns False, an
object-level only permission will never get the chance to check its
object-level logic. Rather than being ignored, NotImplemented should be
treated as true logic-wise (it is in Python) but with lower precedence than
any other truthy value.

In Python 3.9, evaluating NotImplemented in a boolean context is deprecated.
So permissions must use a custom truthy value instead to indicate that
`has_permission` defers granting/denying access until object-level permissions
can be checked and vice-versa, `has_object_permission` defers permission to
the view-level permission.

Also, updated docstrings and documentation.