Issue #2773021 by andrew.lieffring, AdamPS: Query altering fails when table alias "users_roles" is in use

2) Use module chain_menu_access for better results with other access modules enabled and simpler code.

Put the "no custom roles" permissions back to how it was in version 1 to avoid confusion on upgrade.

Create a new "access users overview" permission.

There are too many interlocking changes to commit each one separately.

1) Permissions (administerusersbyrole_permission)

    Drop the "and other roles" permissions as per #2379013: "XX and other roles" permission can give admin access by accident.
    Internal permissions names use role ID not role name (user visible permission titles are unaltered). This fixes several problems. Title can be translated; title can change; title can contain special characters, which are stripped, but then two different roles could collide.
    For simplicity and efficiency, no need to have special case for "no custom roles" - we can just use role ID DRUPAL_AUTHENTICATED_RID. (Except we do special case the title to help users.)
    Now we are no longer relying on 'administer users' permission, we need a base permission that enables the function of this module (e.g. to govern access to admin/people). The neatest solution seems to be to use the "no custom roles" permissions. Hence there is ...

Issue #1940874 by mrfelton: Fixed Unable to edit username or status if granted to permission to edit a user account by administerusersbyrole.

Issue #1677874 by mrfelton: Fixed Access checking in hook_user_update() breaks api calls from rules.

Issue #923882 by mrfelton | steveparks: Fixed Install warning when Administer Users by Role is activated by an installation profile.