Three hand-rolled copies of the unlink-then-rename fallback, with two different return conventions

[xroche]

RENAME does not clobber an existing target on Windows, so every caller that moves a file over another writes the same unlink-then-retry dance by hand. There are three now:

• replace_file(), src/htsback.c:593 — returns hts_boolean, passes paths through untouched
• wacz_rename_over(), src/htswarc.c:987 — returns 0 on success like rename(2), and runs every path through fconv()
• the inline block in singlefile_rewrite_file(), src/htssinglefile.c:1092 — hts_boolean again, no fconv()

The duplication is not really the problem. The drift is: two opposite return conventions, and only one of the three converts separators. Pick the wrong one to copy next time and you get either an inverted success test or a silent no-op on a /-separated Windows path.

One helper in htstools.c with the fconv() behaviour and an hts_boolean return covers all three call sites.

This did not land with #720 because folding two shared files into a feature PR buys review risk for no functional gain. It wants its own change, and a test that actually exercises the clobber path rather than just the happy rename.

Noticed while reviewing #720.