[Feature] Init/ErrorHandler: Introduce ShouldNotAutoReport interface

[mjansenDatabay]

This PR introduces a way to mark exceptions so that they are not reported by ILIAS' global error handling, and adds documentation for the Error Handling roadmap.

Marker interface

• New interface: ILIAS\Init\ErrorHandling\Exception\ShouldNotAutoReport in components/ILIAS/Init/src/ErrorHandling/Exception/ShouldNotAutoReport.php.
• Exceptions implementing this interface are not reported: no log file is written, and nothing is written to the application log or PHP's error_log() when they are handled by Whoops' default and logging handlers.
• The user still sees an error page (by being redirected to error.php); only the reporting step is skipped.
• Use this for expected or high-volume exceptions (e.g. routing/dispatching failures, invalid request parameters) to avoid log noise and unnecessary I/O.

ilErrorHandling

• defaultHandler() (for production env.): if the exception implements the new interface, no log file is written, and the user sees a generic error message instead of a "logfile has been created" message.
• loggingHandler(): if the exception implements the marker interface, it returns without writing to the app log or system logger.

Documentation

• README.md in Init/src/ErrorHandling/: describes the new marker interface, when to use it, how ilErrorHandling uses it, and a short usage example.
• ROADMAP.md: short-term goal to get rid of redirects to error.php from the default exception handler and respond in-place with the error page (one response per error instead of redirect and second request, this is related to [Improvement] Init: Introduce ErrorResponder (first usage: handle ilCtrl routing errors as HTTP 404) #11110).

Motivation

• Lets components opt out of reporting for specific exception types without touching global handler configuration.
• Reduces I/O and log volume for expected or client-side failures (e.g. bots, broken links).

[mjansenDatabay]

Dear colleagues (not only the assigned co-authorities, but any developer interested in this topic),

do you have and thoughts about this? Objections? Approvals/Likes?

Best regards,
Michael

[kergomard]

Hi @mjansenDatabay

Thank you very much for this proposal!

I think, I understand the motivation for this. I'm skeptical about the approach, though:

1. As always, I do think this should not be left to developers to decide.
2. Is it even right that these cases trigger an Exception shouldn't we rather try to catch the problem and show a proper message before it does that? This rather feels like treating symptoms.
3. I think we should keep things consistent, without having to look around for the implementation of an interface.

If we think we need this: Shouldn't this rather be linked to the logging levels?

Personally, I would suggest that, if really needed, the list is probably a well defined one, that we as a community can agree upon and that should be kept centrally. If we decide that we would like to have this available for custom components (I'm rather unsure we do), we should have a process to agree if an Exception in the ILIAS namespace falls into this category or not.

So far my five cents.

Thanks again and best,
@kergomard