largefiles: use uipathfn instead of match.{rel,uipath}() (API) All callers now pass in a uipathfn, so we can just use that instead of choosing the right match function. This also means that when we make add/remove respect ui.relative-paths, it will work for largefiles too. Differential Revision: https://phab.mercurial-scm.org/D5904

forget: pass around uipathfn and use instead of m.rel() (API) Differential Revision: https://phab.mercurial-scm.org/D5911

addremove: pass around uipathfn and use instead of m.uipath() (API) Differential Revision: https://phab.mercurial-scm.org/D5903

remove: pass around uipathfn and use instead of m.rel() (API) Same as previous commit, but now for remove. Differential Revision: https://phab.mercurial-scm.org/D5902

add: pass around uipathfn and use instead of m.rel() (API) For now, the uipathfn we pass around always prints relative paths just like before, so this should have no effect. Well, there's one little change: I also made the "skipping missing subrepository: %s\n" message relative. Differential Revision: https://phab.mercurial-scm.org/D5901

subrepo: (mostly) use relative path in "skipping missing subrepository" This is consistent with the other messages printed by these functions. Note that addremove is a little different and prints absolute (aka repo-relative) paths if no argument was given. Differential Revision: https://phab.mercurial-scm.org/D5900

subrepo: use relative path for "already tracked" message From 932de135041f (subrepo: warn when adding already tracked files in gitsubrepo, 2015-02-27): The file is printed with abs() to be consistent with how it is printed in workingctx, even though that is inconsistent with how added files are printed in verbose mode. However, a few year later, the same author wrote 7008f6819002 (context: name files relative to cwd in warning messages, 2017-07-11) and now it's inconsistent. This fixes that inconsistency. Differential Revision: https://phab.mercurial-scm.org/D5899