Be more conservative when validating scopes.

Returning `True` here seems needlessly permissive and can result in scope escalation if developers do not declare a `validate_scopes` method on their client objects.

Imagine that a client requests a token with scopes `['read', 'write', 'destroy']` but the default scopes for this client is `['read', 'write']`.  If a `validate_scopes` method is not defined on the client object, the first conditional here will return `False`:

```python
def validate_scopes(self, client_id, scopes, client, request,
                    *args, **kwargs):
    """Ensure the client is authorized access to requested scopes."""
    if set(client.default_scopes).issuperset(set(scopes)):
        return True
    if hasattr(client, 'validate_scopes'):
        return client.validate_scopes(scopes)
    return True
```

If I haven't defined that method on the second conditional, a provider using this default method will approve the generation of a token with more scopes than it should be allowed to have.

----

I realize developers can currently avoid this behavior in two ways:

- Subclassing the request validator and implement their own `validate_scopes` method to be less permissive
- Adding a `validate_scopes` method to their client objects.

Regardless, it seems weird to have the most permissive and possibly dangerous option be the default one.