Create separate sub-module for the fixes to alter the User module forms.  Hopefully this code can be deleted when core has been fixed.

- Issue #2853303 by shawn_smiley, AdamPS: Cannot notify users of created account
- Problems mentioned in #2826568 comment #3

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

- Expose read-only access to some more fields
- Hide rows in view where there is no edit access
- Fix line endings

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 a small change to the meaning of these permissions: to edit a user requires "edit users with no custom roles" plus the specific permission per role of the user.
    Pointless to have a permission for anonymous user.

2) Menus (hook_menu_alter).

    Add permission hook to view user to ensure that blocked users are visible when we have permission to edit them.
    Add permission hook to allow creation of users based on permissions.
    Add permission hook for admin/people for users that have some edit or cancel permissions.

3) Calculation of access (_administerusersbyrole_can_*)

    Always start by calling the existing functions in the user module (such as user_edit_access),rather than attempting to duplicate the logic, and leading to bugs where it's not identical.
    Never allow UID 0 or 1.
    The code in the user module to create and cancel users relies on 'administer users' permission, so we simulate this similar to the Subuser module (thanks to BWPanda in #1717876: Remove dependency on 'Administer users' permission).
    On the admin/people page, only show users that are editable - this is important to ensure that bulk operations are subject to the permissions checking.
    Fix bug causing error messages on cancel confirm (administerusersbyrole_form_user_multiple_cancel_confirm_alter).
    Fix bugs in visibility on user edit form (administerusersbyrole_form_user_profile_form_alter); make sure we don't duplicate the logic of the base form function, just add visibility where needed.

4) Views - just minor tidy up

    hook_views_handlers is no longer needed in Views 3.
    _administerusersbyrole_can_cancel_user now calls user_cancel_access so it's a waste of time to call it again.
    Fix the text on the button to match the code now in Views.

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.