Update config setup to be friendlier when using Filemanager as part of another project

I'm primarily using Filemanager as an extension at work so I'm interested in seeing the front-end and back-end modularized, and being able to function independently of each other. Here are the main things I did to decouple them for my project.
1. The config file is shared between front-end and back-end so I moved it into a config/ folder for ease of management. 
2. Paths to Filemanager's internal files set by `__DIR__` to support having Filemanager root folder be in side another project's vendor/ folder. This makes it compatible to be dropped into another project, and follow many popular framework naming convention
3. The config file has options related to paths to different places broken off into its own JSON property for ease of reading.

The code so far has been focusing on the back-end. I will submit another pull request for front-end changes.
I've also done refactoring of the getfolder() to make it easier to read while I was studying the code as well.

Thank you for your work. I appreciate this project very much.
Hmm .. I personally cannot imagine a scenario where a developer would rather run array merge for every requests over updating new config files. It might matter if Filemanager is aggressively updating config file and said developer is updating to the new commit every day. 
On the other hand, there are many diff tool that helps with merging process of the config file including git diff itself as well. It makes updating much easier. This is the same process they have to do if they modified Filemanager's own code base to meet their use cases.
That being said, if you believe this feature is important to the Filemanager's community, I'd be happy to revert the changes. I've only kept half an eye on the issue trackers and most certainly never look pass the first page, I have no idea what the community would want.