move config code concerned with paths in to separate package

[lcowell]

I wanted to resolve issue #211 , but I quickly found that it was difficult to reason about how and when paths are calculated. This is an attempt to centralize the knowledge of paths in the exercism cli.

[Tonkpils]

From looking at the paths package, it seems that all the functions in there still include Path as part of the name. This leads me to question if we actually need another package to handle this functionality or we can just place this functionality in a file called paths.go in the config package and place all that functionality there.

I know there's different views on when to separate packages but I thought it'd be good to discuss it. /cc @kytrinyx thoughts?

Other than that, this looks good and I agree this functionality needs to be grouped together.

[lcowell]

Thanks @Tonkpils - I hadn't even thought of including it in config, but it's possible that it's premature packagization. What would be the advantage of keeping it all in the config package? BTW I've updated the names to be paths.Config() or paths.Exercises() to remove the stutter.

I'm not adamantly opposed to folding it back in to config, but it feels like a separate concern and gives us a nice bucket for other functions relating to paths like paths.IsDir(). I also like that it forces interactions between the areas of code to be explicit (which is how I was able to clean things up). I could also see this being a place where we describe how to construct other paths such as paths to language directories or assignment directories.

[kytrinyx]

I'm a huge fan of tiny packages, and tend to prefer extracting if possible, then if later we find that it's really not worth the stand-alone package, we could easily fold it back in. My vote is for extracting the package now and then living with the decision for a while to see if we like it.

[Tonkpils]

I'm fine with that. I'll go ahead and merge this