Include scope in response if given scopes don't match requested scopes

[robbytaylor]

According to RFC674:

The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.

https://tools.ietf.org/html/rfc6749#section-3.3

This PR adds a scope parameter to the Bearer token response when the token's given scopes are different to the scopes that were requested.

[robbytaylor]

I added the request object as an argument to ResponseTypeInterface:: generateHttpResponse() because it seemed like a preferable (i.e. more generic) approach than adding a $requestedScopes parameter.

I allowed the request parameter to be null, partly because there's places where a redirect response is generated which don't have the request instance available. It didn't seem sensible to update unrelated methods to pass the request object only so it can be passed to the redirect response, which doesn't even need it. I also thought it might help backwards compatibility for libraries which depend on this one. But let me know if you can see a better way of approaching it.

[Sephster]

Hi @robbytaylor. I'm not sure about the change to the generateHttpResponse interface as you have pointed out in our comment. I also note that this is currently failing our PHPStan checks. Could you resolve this first and then I will take another look? Many thanks and sorry for the delayed response with this one!

[robbytaylor]

Hi @Sephster, thanks for getting back to me on this. Will do.