shred: fix direct I/O failures for last write to file

Since direct I/O is now enabled with commit v8.21-139-gebaf961
we must handle the case where we write an odd size at the
end of a file (with --exact), or we specify an odd --size that
is larger than 64KiB, or in the very unlikely case of a device
with an odd size.  This issue was present since direct I/O
support was first added in v5.3.0, but latent since v6.0.
Theoretically this could have also been an issue after that on
systems which didn't have alignment constraints, but did have
size constraints for direct I/O.

* src/shred.c (dopass): On the first pass for a file, always
retry a write that fails with EINVAL, so we handle direct I/O
failure at either the start or end of the file.  Adjust the comment
as the original case is out of date and implicitly handled
by this more general fix.
* tests/misc/shred-exact.sh: Add a test case.
* NEWS: Add a "bug fix" entry for shred since there are
two related issues now fixed.
shred: increase I/O block size for periodic pattern case

* src/shred.c (dopass): In the periodic pattern case increase the
I/O block size from 12KiB to 60KiB (also a multiple of 3 and 4096).
* NEWS: Adjust accordingly.
shred: avoid data write pass with --size=0

* src/shred.c (dopass): Exit early to avoid redundant heap
allocation, and more importantly avoiding a file sync
when we're writting no data, as this can have side effects.
Also with --verbose, this avoids printing of "pass status"
which could be confusing as to whether data was actually written.
* tests/misc/shred-passes.sh: Ensure the status for data
passes are not written when not doing any data writes.