addremove: restore the relative path printing when files are named
This fixes the previously mentioned issue with 3778884197f0, and undoes its
corresponding test change.
The test change demonstrates the correctness when a file is specified (i.e. the
glob is required on Windows because relative paths use '\' and absolute paths
use '/'). It is admittedly very subtle, but there will be a more robust test in
the addremove -S v3 series.
warning
error
'buffered\n'
colored? True
colored? True