Currently when detectors see errors, we get a single line with multiple errors.

In https://blog.pope.tech/2023/09/26/form-accessibility-and-usability-beyond-the-
basics/#error-message-pattern

they advocate for using a list of errors rather than a single line. This provides feedback
to users with assistive devices on the number of issues reported.

One thing I don't remember is whether multiple auditors can run and generate multiple
errors or if the first auditor to report a ValueError or other stops the execution
of following auditors.

So it may be the case that we only return one error at a time. But I think I have seen
multiple errors. However they may not have all been generated by detectors.

Implementation notes:

In the cgi framework, add_message appends a message to the self._error_messge or
self._ok_message lists. So it should be easy to put a title/subject for the output error
message box and generate a series of list elements inside a ul or ol element.

Ideally we should be able to add a link or other element from the error message to the
input field with the error message (where applicable).

Also it should be possible to add a feedback message at the location of input with the
error.

Both of these would require some additional work.

Maybe modify the RejectBase exception to add a property field? The
property name could be used to identify the input and generate the error
message with the input when the form is rendered.

Also this raises an interesting question. Reject is documented as the way to stop
the commit of the database change from an auditor (IIRC it has no effect in a reactor).
AFAICT it is meant to notify the user of a problem that the user can fix. Sort of a 4xx
error in HTTP.

Do we need an equivalent exception to a 5xx error in HTML? If so does it get propagated
to the user in some form? Do we already have this with the exception flow that results
in the user getting "Something has gone wrong the administrator has been notified."?

Ralf previously identified some issues with generic python exceptions resulting in error
feedback for the user in issue2551127. Maybe this could start work on cleaning that up.