Use read, rather than awk to address NUL byte handling issues

[aaronjensen]

Fixes #213

From what I can tell, accomplishes the same as the awk usage without relying on the NUL byte behavior of particular versions of awk.

I didn't add any new tests because it relies on a specific version of awk to produce the issue, but all existing tests still pass aside from one, which failed prior to my change:

 ✗ merge: branches with encrypted file - line changes both branches, with conflicts

[aaronjensen]

3f24e9d addresses the test failure I saw

[jmurty]

This is a clever fix, thanks very much!

I was concerned the different approach might cause much slower performance, so I tested the impact by comparing the old awk command against this new read approach processing a list of over 30,000 NUL-delimited file entries.

On my system the new read approach is about 10 times slower to process the 30k entries, but still takes only about 0.88 seconds to do so while the awk approach takes about 0.08 seconds. It's a shame it's slower, but I think the impact is small enough even in repos with many files that the improved compatibility is worth the change.

Merged to main

[aaronjensen]

Ah, interesting. Performance didn’t even cross my mind, good call. Thank you for the merges and transcrypt itself.