Improve flow between classifying as delivery error and making a public body change request

[garethrees]

Via #8000 (review).

Currently:

• A user receives a bounce message to their request
• They classify as a delivery error (error_message). At this point they get asked to look for a new address, but:
  • They probably don't want to interrupt their flow right now
  • If they do, the form we provide is just a plain text box unconnected to the PublicBodyChangeRequest system
• Since [#1782] Help us CTA from delivery error message #8000 we now signpost them (and other users) to the change request form for the body
• They can then go and source a new address and submit, but that change request isn't linked back to the request that spawned it, so we'll have to manually tie back the error_message report we get and then the subsequent change request report.

Ideally:

• We wouldn't get emailed immediately when users classify as error message; that should be an active "ask us for help" request (maybe via the "report this request for admin attention" flow)
• We'd get a periodic digest of delivery issues so that we can review as and when we've got time
• Change requests could be parameterised and linked back to a request (e.g. via /request/foo/public_body_change_request/)
• We'd improve the change request form to handle e.g. users submitting the existing email; users submitting the same email as a currently open change request, etc.

[HelenWDTK]

This issue has been automatically closed due to a lack of discussion or resolution for over 12 months.
Should we decide to revisit this issue in the future, it can be reopened.