Framework Preparation for Service Layer

Addresses #138, #139
Foundational for #125, #161

First thing, I'm sorry about the large PR. I don't like to submit this much stuff at once, but this PR represents some larger foundational changes so I couldn't really break it up too much.  

This breaks the current PHPUnit tests completely and **shouldn't be merged until the build is passing**. I am creating this pull request to get the current changes on the table and up for comments. My intention is to start working from here writing new tests that will be targeting a service layer that can be more easily tested (as its collaborators should be easier to mock/stub). 

Goals:
* Get us to the point that features can be exposed to multiple entry-points.
* Improve boundary integrations with third-parties with hopes to improve testability and reduce risk of upstream dependence.
* Work towards freeing our domain logic from infrastructural concerns to make it more flexible to the addition of new features.

Here's the highlights on changes:
1. `OpenCFP` namespace was restructured with multiple entry-points to a common application service layer in mind. This includes:
   * `Http` namespace for current web-interface controllers and a future JSON-API to be discussed
   * `Console` namespace for command-line commands
2. `Bootstrap.php` replaced by `Application.php`, which is now responsible for binding configuration and registering many service providers.
3. Addition of a `Providers` namespace where future service integrations would be located and registered with the `Application` container.
4. Configuration format and schema has changed for all environments. This change was made because there happened to be a Silex configuration service provider by Igor that served the purpose very well.  In addition, Yaml was chosen as the configuration format because it's easy to serialize (in the case end-to-end tests needed to change application config).
5. Various cleanup tasks resulting from restructure. This includes things like removing the `schema.sql` since it is now in a base migration, correcting templates, removing obsoleted tools / classes, etc.
6. Shiny README changes...

Next steps:

1. Work on writing tests + service layer for use by controllers
2. Write an `install` command to facilitate the installation process outlined in the readme
3. Add developer-oriented documentation to guide where work should be done (where to put commands; basically, the lay-of-the-land)
4. Complete Behat tests for administrator features as part of writing other tests + service layer for those parts of the application.