tor-config-path: refactor to support a `CfgPathResolver`

This MR changes tor-config-path to use a CfgPathResolver for expanding variables in CfgPath, rather than a static hardcoded list (ARTI_CONFIG, ARTI_CACHE, etc). The hardcoded list is inflexible and doesn't offer a good way to support different variables for arti-relay. (See this thread for possible other approaches.)

This changes the path method of CfgPath from:

pub fn path(&self) -> Result<PathBuf, CfgPathError> {

to:

pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {

(And similarly for CfgAddr::address.)

This means that we need to define the variables (and the new resolver) in arti-client and pass that resolver around within the arti crates to whatever code needs to expand CfgPaths. Luckily this only happens in two libraries: tor-hsservice and tor-ptmgr.

This is a breaking change to CfgPath (tor-config-path is a 0.x crate), but existing users of CfgPath::path() can update their code to CfgPath::path(arti_client::config::path_resolver()) instead to have the same behaviour.

The resolver is not configurable for TorClients since it would require some small breaking changes to the public API of arti- libs. But other crates like arti-relay, which doesn't need to use TorClient, would be able to configure their own resolver.

Part of #1672 (closed).