Rationalize how we get roles after authentication in the controllers

Currently there is a mixture of strategies in the v2 and v3 controllers
for how to get the roles assigned for the scope of the requested
authentication.  This duplicates code, is hard to maintain and in at
least once case (where your only roles on a project are due to a group
membership) is not actually correct (for v2 tokens).

This change does the following:

- Standardizes on using the 'get_roles_for_user_and_project()', and its
  domain equivalent, for how roles are obtained to build a token.  This
  was already the case for v3 tokens.  The controllers no longer need
  to get metadata and extract the roles.
- Removes the driver level function to 'authorize_for_project' - this is
  now handled wihin the controller.  The driver simply supports the user
  authentication.

A nice (and planned for) sideffect of the above is that we now hide
the schema of how we store roles within the driver layer - i.e.
nothing outside of the driver (other than any specific-to-implementation
tests) have to know about how roles are stored in the metadata.  This paves
the way for a re-implementation of the grant tables in IceHouse.

This change also fills in missing function definitons in the assignment
driver.

Implements bp authenticate-role-rationalization

Change-Id: I75fc7f5f728649d40ab1c696b33bbcd88ea6edee
Merge "Rationalize how we get roles after authentication in the controllers"