extract retarget_path/2', relative_path/2' and `reduce_path/1' and add tests

[talentdeficit]

useful in more contexts than just rebar_prv_common_test and this allows tests

they're currently duplicated in rebar_prv_common_test but will be removed in a separate pr once (if) this one is accepted

[ferd]

This seems reasonable. I tend to associate reduce with a fold-like operation given map-reduce and python functionalities, but that's the only confusing thing there I believe.

[tsloughter]

What about rebar_dir:make_relative_path/2? Isn't that the same as this new rebar_file_utils function?

[talentdeficit]

no, make_relative_path is bidirectional and will produce paths like ../../path and also doesn't do any kind of normalization of input. relative_path will only produce paths if they are ancestors of the base path.

the names are not great, they were taken directly from rebar_prv_common_test where they were private functions. the following name changes might make sense:

relative_path -> path_from_ancestor
reduce_path -> canonical_path

[ferd]

Those seem fair. Would you expect canonical path to yield me an absolute path too?

[talentdeficit]

it doesn't have to be an absolute path, just one that we can rely on to be stable on multiple calls to canonical_path so we can compare paths more easily. filename:absname is just an easy way to get that

[ferd]

Sounds good then