Handling of problematic attachments needs to be done gracefully

This issue is being carried over from https://github.com/eikek/docspell/issues/2376, and is about the situation, where an attachment of an email, or an archive component has been misclassified (see #2403), thus causing Docspell to pick an interpreter for the identified file type, which is then likely to fail.

If an interpreter/converter fails to interpret/convert a given attachment (with a given content type), then it seems there might be three possible explanations:

1. the tool had a temporary failure, e.g. memory exhaustion or cosmic rays;
2. the tool had a permanent failure, e.g. a bug, or a corrupt input file, or an alien invasion;
3. the wrong tool was picked to do the job.

The first of these can possibly be countered with a retry or two. The second and third will never terminate in an acceptable result. This issue is about what would be the best course of action for Docspell in such cases.

Currently, Docspell will retry, but if a failure doesn't resolve itself, it will skip remaining attachments, skip post-processing (OCR & preview images), and it also won't invoke addons or `job-done` webhooks. The generated item will be obviously incomplete for the user to take note, though it is questionable what options the user has. In the case of an email message with an unexpected attachment, it might be too much to expect the user to perform surgery on the MIME tree, in an attempt to fix things.

I would like to argue that in all three of the above cases (when temporary failure isn't resolved during `n` retries, and 2–3 unchanged), it would be better to take on the raw original of the problematic attachment, but continue processing the pipeline just like as if the attachment had been processed just fine. The end result will be a series of attachments to an item, but any unconverted, raw ones will simply sit there, without the browser able to display them, and only able to offer a raw download of the attachment in question. Addons and webhooks can do whatever they want, they might even *expect* the attachment, and be able to do more with it.

When OCR and preview generation encounter a raw attachment, they should just skip it. And yes, addressing this issue might also involve touching the UI to improve handling/display of raw attachments.