Rationalize how user roles are obtained at authentication time

The auth/token controllers have different strategies of obtaining the list of user project/domain roles at authentication time - with varied use of the optional project id available in the identity driver authenticate call. Only the v2 authenticate_local uses this feature, the others (external and token) and all v3 read the roles for the project after authenticating with just the user details. Further the v2 code builds the roles lists by hand (allowing for groups), while the v3 version calls the "get_user_roles_for_project" (or "domain", which does that for you. This mismatch is not only bad for maintenance, but is also wrong in some cases (e.g. if the ONLY role you had on a project was by nature of group membership, authenticating locally would fail).

We should rationalize this - and always just authenticate for the user and then call the "get_user_roles_for_project" (or "domain") within the controller.