Refactor Benefits admin permissions as methods on ModelAdmin classes

[angela-tran]

From the discussion in #2654 (comment), we've decided the logic that decides which models a user or group can access and their level of access should be defined explicitly in code instead of using the built-in permissions system from Django. This would make it more similar to how we define which fields a user or group can access and their level of access.

This means that the permissions we've been adding to the Cal-ITP staff group should instead be implemented by overriding the has_view_permission, has_change_permission, has_delete_permission, and has_add_permission on the ModelAdmins we've defined.

We'll also want to remove any UI that exposes the permission system since it won't have any effect.

• "Permissions" field on Group
• "User permissions" field on User

Acceptance Criteria

• Cal-ITP group has same levels of access to models as before
• No UI in Benefits Admin that does anything with Permission objects
• Unit tests for our new methods