Implement common service code.

[DanNiESh]

I followed the suggestion from Mainn and implemented the common service code. This pull request does not show the work on database models. I imitated esi-leap code, created config files in conf folder, created service.py in common folder and also changed some files in api folder. Now we can run the project with "sudo flocx-market-api", which is the entrypoint flocx_market.cmd.api:main (hopefully, if the pythonpath is correct) I have some problems though:

1. When I run the project in my virtualenv with "sudo flocx-market-api", I get the error like "module not found". It's because it searches global python path for importing python modules but I installed the packages in the python inside my virtualenv. (I did export PYTHONPATH="/path/to/virtualenv/python, not working) However, if I run the project by "python flocx_market/cmd/api.py, it would work.
2. I cannot fully understand every part of the codes that I've made changes. Correct my work if some of the codes are redundant or can be better.

[tzumainn]

Hi! This is looking good. I'm going to have a few random comments:

• You probably want to start using git rebase rather than git pull. The latter creates merge commits, while the former will re-apply your branch commits on top of any changes that might have happened on master.
• There are some merge conflicts that you'll need to resolve.
• It probably makes sense to squash some commits together - for example, the .gitignore updates.

I know this can be confusing, so if you want to walk through this stuff together sometime, just let me know!

[larsks]

@tzumainn @DanNiESh if you haven't seen them already, I wrote up this article on making good pull requests and commit messages, and this one about squashing together a troublesome pr.

[tzumainn]

Overall, I think the code looks good! I would encourage you to separate out the commits into smaller bits of work. Separating out the .gitignore commit is good; I'd go further by making separate commits for:

• the files in conf/
• the update to the code in api/ to use the conf parameters

And other small, discrete updates that make sense by themselves.