[TASK] Refactor to add AbstractPageController and PageControllerInterface
[TASK] Use new method in Flux ConfigurationService to get top Provider
[TASK] Adjust Exception message when Provider cannot be resolved

Adds a bit more detail and fixes a missing "a".
[TASK] Implement Flux's Debug Service
[TASK] Refactor to AbstractFluxController
[TASK] Implement PageControllerInterface
[TASK] Change old registration of FED extensionKey in Provider
[FEATURE] Detect and use Page Controller associated with collection

This change enables a new breed of Controller: the PageController. If such a Controller exists in a package which provides page templates, FluidPages tries to use methods on that Controller to execute a sub-request where each method on the Controller corresponds to a page template which can be selected in page properties.

The methods will only be attempted if they do in fact exist and errors are caught, logged for debugging and the "errorAction" of FluidPages' own PageController is called (but renders the Error.html template from the associated extension if possible).

Use this to be able to…

* Catch and react to Exceptions on a page level including every possible Exception thrown by plugins in use on the page. If the error is considered fatal, display an error page. If you need to, use advanced error messages.
* Insert template variables from an actual ControllerContext, for example various aspects of the Request being rendered.
* Have a proper ControllerContext which points to your carrier extension instead of, as is default behaviour, pointing to FluidPages.
* Accept and use URL parameters for your page.
* Use Repositories (not just from your own extension!)
* Detect user logins (using FrontendUserRepository) and change rendering
* Everything you're used to doing with Controllers.
Merge pull request #22 from NamelessCoder/controllers

[FEATURE] PageControllers in carrier extensions