Validate confidential clients and determine if the client handles the grant type

[hafezdivandari]

Fixes #1174
Fixes #1369
Fixes #1073
Closes #1036

This PR can be considered as a security enhancement and does 2 main changes:

1. Validate confidential clients:
   • RFC6749 section 3.2.1
   • The "auth code" grant calls AbstractGrant::validateClient() only if the client is confidential (RFC6749 section 4.1.3). But "device authorization", "refresh token" and "password" grants always validate the client secret. This PR allows public "device authorization" (RFC8628 section 3.4), "refresh token" (RFC6749 section 6) and "password" (RFC6749 section 4.3.2) clients by calling the ClientRepositoryInterface::validateClient() method only if the client is confidential.
   • Fixes Support Public Clients for Password and Refresh Token Grant #1073
   • Fixes RefreshTokenGrant requires client_secret also for non-confidential clients #1369
   • The "auth code" and "client credential" grants unnecessarily call AbstractGrant::getClientEntityOrFail() twice instead of just using the AbstractGrant::validateClient() return value, this PR fixes that.
   • All grants except "client credentials" grant (RFC6749 section 4.4) can be non-confidential. It's already implemented this way on most community integrations:
     • Passport
     • Symfony
     • Mezzio
     • Drupal
2. New ClientTarit::supportsGrantType() function:
   • RFC6749 section 5.2
   • Fixes Add Unauthorized_Client support #1174
   • This function is implemented on ClientTrait that returns true by default to avoid BC breaking changes.
   • Currently there is no way to check if the client handles the grant type before proceeding the request, e.g. We don't want to make auth code on "auth code grant" or make device code on "device code auth" grant or response with the access token on "implicit token" grant if the specified client doesn't handle the grant type. This PR makes this possible to avoid handling the requested grant type if the specified client doesn't supports that.
   • It also makes it possible for us to disable issuing refresh token if the client doesn't handle this grant.

[Sephster]

This looks good @hafezdivandari - I like the way you've supported the unauthorized_grant without introducing breaking changes. A nice solution.

Only concern I have is around the validation of the redirect URI. I've left a comment. Thanks for your hard work on this