Add bootstrapper with flask-based comm. manager & a few clean ups

[georgymh]

This pull request's major change is the addition of the Bootstrapper (see the UNIX Service wiki on Quip for more information).

In details, these are all the changes:

• Add a Communication Manager (only with listening capabilities, not sending) for debugging based on Flask

  • The Listener has 4 endpoints that create (initialize type) jobs, view the status of the scheduler, and heartbeat

• Add a working Bootstrapper using the Communication Manager above

  • Runs 2 threads, one for the Scheduler's cron and the Communication Manager's listening loop (we use threads so we can share data between these classes)

• Add a setup.py and __main__.py so we can package and run the codebase without explicitly calling python (instructions added to the README)

• Miscellaneous fixes / clean up:

  • Remove the singleton pattern from the Scheduler (we are choosing dependency injection on all current modules now) and update the tests
  • Remove the status from the Runner (since the Scheduler manages the Runners, we put all bookkeeping in the Scheduler and the Runners only run stuff asynchronously)
  • Make the Dataset Manager import "context" from core/utils rather than tests/ so we can correctly package the codebase without having to include the tests
  • Fix a typo in dmljob.py
  • Rename the Configuration Manager tests to follow previous conventions
  • Update .gitignore to not include configuration.ini or packaging meta-files

[neeleshdodda44]

Are there going to be tests for the Bootstrapper/Communication Manager/Listener?

Seems kind of nitpicky for Communication Manager/Listener (tests for components used for testing), but I was just wondering.

[georgymh]

I think writing tests should be prioritized for modules that would go under considerable changes over their lifetime.

So the Communication Manager and Listener (which will be embedded in the Communication Manager) should definitely have tests.

As for this Listener, I decided not to write tests since it's only used to manually debug the service and we don't expect to be changing it much. It's not a critical component.

The tests for the Bootstrapper will probably be integration tests, but we need to finish the other modules before writing those. I don't think unit tests make a lot of sense for the Bootstrapper right now.

[georgymh]

Perfect, thanks @neeleshdodda44.

@nzoghb, I'm waiting on your review for the multithreaded & multiprocessing parts.

[georgymh]

@nzoghb: Yes, those few bits. If you don't see any problem with them, I will go ahead and merge. I fixed the test & private method issue and left a comment above.