Harden server-side encryption against Byte-Order Marks (BOM)

When using server-side encryption, we currently rely on the header starting strictly on the first byte. This isn't always the case when some sort of errors or configuration mistakes happen.

Possible cases can be:

• The file was marked as unencrypted in the database and an application adds a BOM to the file during their attempt to read them anyway, which is then being saved within Nextcloud. Example: Using PowerShell 5.1 Set-Content with -Encoding UTF8 (or -Encoding UTF8BOM for PS 7.0+) being set
• Using S3 with some kind of DPI between Nextcloud and the object storage with a configuration being enabled that modifies the file content (which shouldn't happen, but is possible as we don't send over the files as Content-Type: application/octet-stream, which would be the correct way)

Example header content for such a case (important: there are more BOMs that could occur!):

    the first 20 bytes actually are:
      hex:   ef bb bf 48 42 45 47 49 4e 3a 6f 63 5f 65 6e 63 72 79 70 74
      ascii: ...HBEGIN:oc_encrypt

In these cases, the file is being unrecoverable by any of our occ encryption commands, leading to the impression we corrupted the file during encryption and manual backups must be used.

We should harden the server-side encryption, so we ignore any BOMs in front of the header itself or at least make it self-recoverable in any way.