File type detection flaw during email/archive processing

This issue is being carried over from #2376, and is about the situation wherein during email processing is being mis-identified. It's a minor issue in and of itself, but might be symptomatic of a bigger problem.

Below you will find an email that encodes an attachment of a file named `d0101c66_mySQL40.sql`. Docspell currently classifies this as a `text/x-sql` file, which it isn't. `libmagic` 5.45 thinks it is a binary of type "MacBinary III INVALID date" (possibly corrupt), which is close(r), because the file is in fact binary.

To recreate the file, take the three Base64-encoded lines from the email and pipe them through a Base64-decoder, such as `base64 -d`.

Arguably, Docspell should use `Content-Type: application/applefile` as and if provided. In the absence of an explicit `Content-Type` header, any uncertain file should probably become `application/octet-stream`. Binary files should definitely not become `text/*` files.

```
Date: Sat, 11 Nov 2023 21:54:36 +0100
From: invalid@example.org
To: invalid@example.org
Subject: Docspell test email
Message-ID: <20231111205436.oefruzlox57xssbt@example.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="holmsj2d6wm2cnnr"
Content-Disposition: inline

--holmsj2d6wm2cnnr
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Check attachment

--holmsj2d6wm2cnnr
Content-Type: application/applefile
Content-Disposition: attachment; filename="d0101c66_mySQL40.sql"
Content-Transfer-Encoding: base64

ABRkMDEwMWM2Nl9teVNRTDQwLnNxbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbUJJTgAA
AAAAAAAAAAAAAAAAAACCgf+/AAA=

--holmsj2d6wm2cnnr--
```