git-crypt inconsistent handling of empty files [portability broken by OS patches]

With two installs of `git-crypt`, both claiming to be `0.6.0`, one on Ubuntu Focal (20.04) and one on an LXC container running Alpine Linux (so musl libc) 3.12.0, both with git-crypt installed from OS packages, I'm seeing conflicting behavior in handling an empty file.

ldd on Alpine

```
/lib/ld-musl-x86_64.so.1 (0x7f3b96eea000)
libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7f3b96c4c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f3b96ab3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f3b96a9f000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f3b96eea000)
```

ldd on Ubuntu, package 0.6.0-1build2

```
linux-vdso.so.1 (0x00007ffedad98000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007ff7fbefe000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff7fbd1d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff7fbd02000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff7fbb10000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff7fbb0a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff7fbae7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff7fb996000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff7fc225000)
```

git check-attr

```
% git check-attr -a homedir-links/_.mutt/server-certificates
homedir-links/_.mutt/server-certificates: diff: git-crypt
homedir-links/_.mutt/server-certificates: filter: git-crypt
```

With either version, if the other version last touched the file then this version shows `M` in `git status` but `git diff` can't show a diff. With the Ubuntu version, `git cat-file -p $blobid` shows encrypted content. With the Alpine version, the same shows that the file contents as committed to the repo are empty.

The Alpine OpenSSL is from package `libcrypto1.1-1.1.1g-r0`, the Ubuntu OpenSSL is from package `libssl1.1-1.1.1f-1ubuntu2`

At this point, my best guess is that some error return differs between musl and glibc and git-crypt doesn't handle them equivalently, and this uninformed speculation led to the issue title I've chosen.