Admin: organize distinct app components

[thekaveman]

Right now, the code that implements what we call the Cal-ITP Benefits Administrator (or "the Admin") is dispersed across a number of different locations, some with a higher degree of organization and cohesion than others:

• Top level templates (both Django overrides and custom templates) in benefits/templates/admin and benefits/templates/registration
  • Including 4 different base templates as of the work in Admin: Header theme, remove darkmode toggle & breadcrumb theme #2773
• Login and permissions setup in benefits/core/admin/users.py
• In-person feature implementation in benefits/in_person/

As we have already started introducing users to the Admin (e.g. #2672) and will eventually need to roll out new features, now is the time to get a better handle on the way we model and build this "other" system.

Let's identify and organize the existing components of the Admin and build on our more recent discussions around longer-term maintenance and scaling of the "main" Benefits app, including:

• Utilize smaller Django apps that encapsulate specific, more self-contained functionality
• Reducing the template burden
• Creating reusable patterns and flexibility for future use-cases
• Reserving the top-level for truly Benefits-wide config a la settings.py or absolutely necessary Django overrides

One approximation of the existing Cal-ITP Benefits Administrator system components is:

• An Agency dashboard, which forms the entrypoint for agency users into the Admin
  • The In person feature, already well-organized into its own Django app
  • The Transit processor portal link
  • The Enrollment history feature (essentially, an agency user's view of the list of EnrollmentEvent)
  • An Agency configuration area (essentially, an agency user's view of the Django model configuration)
• The Django model configuration for Cal-ITP users and superusers

Acceptance Criteria

• A proposal is made as a comment and/or a series of sub-issues on this issue
• The proposal identifies the existing system components by name
• The proposal clarifies the different system components via a more explicit code organization
• The proposal allows for incremental progress to be made towards its goals

Additional context

Related to the theming discovery and work identified in #2701

[machikoyasuda]

After this ticket is done, having documentation of this organization in https://docs.calitp.org/benefits/ and/or in a README in the app would be good.

[machikoyasuda]

This is not directly related, but do consider where CSS files live and what they are named as well.