Cache loaded config and merge it with defaults

[xPaw]

Fixes #249

[xPaw]

... Do we want to keep ENV here?

[maxpoulin64]

I don't really see a use for it. I would get rid of it. I think the only cases we should use environment variables is for things that can't be in the config file (so, the config path).

[AlMcKinlay]

I'm not really sure why you needed to change getConfig, surely you could have stored config as a private variable, and getConfig just returned config. That would have meant a lot less code changes.

[xPaw]

@YaManicKill There are not enough getConfig calls to warrant keeping it, especially in places where only a single variable is checked.

[AlMcKinlay]

@xPaw At least 6 of the 9 files that are edited are edited only because you removed the function. It's not exactly like a getter is less efficient, anyway. What's the point in changing that?

[xPaw]

@YaManicKill Some of the files were changed to remove default fallbacks (e.g. link.js or userLog.js).

Other files kept it's own stored cached configs (like server.js and chan.js). For consistency I decided to make it a public variable, instead of a function call.

[maxpoulin64]

Other files kept it's own stored cached configs (likeserver.js and chan.js). For consistency I decided to make it a public variable, instead of a function call.

Actually since this is JS it doesn't matter much as objects are always references, so either way you get the same thing in the end.

Another option to make this all shorter could be to do var config = require("helper").config; since most places don't use Helper functions at all.

[maxpoulin64]

Looks fine to me, so I will 👍 and we can improve later. I'm not a fan of using "Helper.config" everywhere and would rather have var config = require("helper").config;, but it's not enough to block this.

[AlMcKinlay]

Fine, whatever. I don't really care enough, I just didn't see the point. So, whatever. 👍 and merging.