Plan the implementation of background task processing

[thekaveman]

As the application grows in complexity and support for numerous user flows and agencies, we should look to refactor the processing of certain tasks out-of-band from the processing of normal web traffic.

The prime example is the sending of analytics events to Amplitude, which currently executes in the same request-response cycle as the user's flow through the app process. Among problems with this approach:

• If the event payload is particularly large or Amplitude is particularly slow, the user may be stuck on a page load waiting for the analytics event request to complete
• If Amplitude is down or otherwise cannot receive the event, the event may be lost forever

A similar example is the sending of errors to Sentry. There may be other use-cases for background task processing in the future, for example related to work coming from #1685

Acceptance Criteria

• A main tracking issue exists documenting the plan, with linked task-specific issues
• Any new Azure services proposed or required are clearly documented with some basic cost info
• Solution considers best practices and norms for Django applications
• Solution considers developer experience and local reproducibility/testability

Additional context

Recent Failed to send (analytics) event errors recorded in Sentry:

• https://sentry.calitp.org/organizations/sentry/issues/72652/?project=3
• https://sentry.calitp.org/organizations/sentry/issues/72653/?project=3