du: tests: fix the H_flag test (primarily grep usage)

[kevans]

Summary

This test attempts to use \t (tab intended) in a grep expression. With the
former /usr/bin/grep (i.e. gnugrep), this was interpreted as a literal 't'.
The expression would work anyways because the tr(1) usage would ultimately
replace all of the spaces with a single newline, and they would match the
paths whether they were correctly fromatted or not.

Current /usr/bin/grep (i.e. bsdgrep) is less-tolerant of ordinary-escapes, a
property of the underlying regex(3) engine, to make it easier to identify
when stuff like this happens. In-fact, this expression broke after the
switch happened.

This revision does the bare basics to fix the usage by using a printf to get
a literal tab character to insert into the expression. It also swaps out the
manual insertion of the line prefix into the grep expression by pulling
that part out of $sep and reusing it for the leading path.

The secondary issue was the tr(1) usage, since tr would only replace the
first character of string1 with string2. This has instead been replaced
by a sed expression, which similary understands \n to be a newline on all
supported versions of FreeBSD.

[ngie]

Is there a reason why tr is being changed to sed?

[kevans]

In D27983#625202, @ngie wrote:

Is there a reason why tr is being changed to sed?

This was supposed to be explained in the final paragraph, but after re-reading I should re-word it still:

The secondary issue was the tr(1) usage, since tr would only replace the first character of string1 with string2.
This has instead been replaced by a sed expression, which similary understands \n to be a newline on all
supported versions of FreeBSD.

Notably, string1 = " " (single character) and thus only gets replaced with the first character of string2, the newline. You end up with expressions like so:

[0-9]+\ttestdir/A/B
testdir/A
testdir/C

Instead of the intended:

[0-9]+\ttestdir/A/B
[0-9]+\ttestdir/A
[0-9]+\ttestdir/C

This was a secondary effect noticed while I was diagnosing the primary issue, that bsdgrep made the test start throwing an error due to \t.

[emaste]