Conf file for repo locations

[RandomGuyOnTheInternet1234]

Uses conf.json for the locations of the repos, instead of just using a default location.

[dgopstein]

This looks really good!

Some thoughts:

1. Probably constants.clj can go away, since the conf can completely replace it.

2. Did you consider using a specialized configuration library instead of raw json? There are a lot of benefits, like explicitly handling multiple users, and multiple environments, like test vs development. See for example:
   https://github.com/yogthos/config
   https://github.com/grammarly/omniconf
   https://github.com/levand/immuconf

3. I saw you made a second pull request where you added the json library. Can you unify these two? Before I pull your changes I want to be able to run your code, but I can't if one won't work without the other.

[dgopstein]

Z:\Github\gcc looks specific to your machine?

[RandomGuyOnTheInternet1234]

Fixed!

[dgopstein]

Using conf values should be shorter/easier.

[RandomGuyOnTheInternet1234]

1. I'm not opposed to keeping constants.clj to declare global variables. For example, when the gcc-path is needed in atom_path_test.clj I accessed it using atom-finder.constants/gcc-path. What do you think?

2. I'm a little confused on what exactly you would like me to implement. I think raw JSON is fine for what I've written so far, but what new requirements would you like me to work on that would better use a specialized config library?

3. Fixed! Sorry, I've used Git very little, so I'm still kind of finding my way around.

[dgopstein]

(2.1) As the json is now, a conf lookup is kinda clunk. It looks like: (:gcc-path (json/read-str (slurp (resource-path "conf.json")):key-fn keyword)).

(2.2) Managing several people's conf files is kinda a hassle, your config settings are different than mine, are different than henry's, managing that ourselves is doable, but annoying, whereas external libraries often make that easier.

(2.3) Building off (2.2) it's usually a really good idea to have a special config setting for test, dev (1-per-developer), and production. Test files can be small and lightweight and required, whereas dev can be big and heavy and optional, and prod can be whatever we need for real paper-worthy results.

(1) What you propose is certainly ok, but I think once 2.1 is addressed, atom-finder.constants/gcc-path is actually more annoying than just (:gcc-path conf)

(3) Great, thanks! No problem, git is a huge headache for the first few dozen times you use it until you get the hang of it. Then it becomes awesome, but it's definitely big and scary regardless.