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.

mercurial/scmutil.py

@@ -730,11 +730,10 b' def addremove(repo, pats=[], opts={}, dr'
     toprint.update(deleted)
     for abs in sorted(toprint):
         if repo.ui.verbose or not m.exact(abs):
-            rel = m.rel(abs)
             if abs in unknownset:
-                status = _('adding %s\n') % ((m.anypats() and rel) or abs)
+                status = _('adding %s\n') % m.uipath(abs)
             else:
-                status = _('removing %s\n') % ((m.anypats() and rel) or abs)
+                status = _('removing %s\n') % m.uipath(abs)
             repo.ui.status(status)
 
     renames = _findrenames(repo, m, added + unknown, removed + deleted,

tests/test-addremove-similar.t

@@ -91,7 +91,7 b' Issue1527: repeated addremove causes uti'
 no copies found here (since the target isn't in d
 
   $ hg addremove -s80 d
-  removing d/b
+  removing d/b (glob)
 
 copies here