[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
[FEATURE] Allow provider extensions to be registered using PHP

This feature requires a PageController to be present in the provider extension. If so, the provider's collection can be enabled from ext_tables.php by inserting:

```
Tx_Fluidpages_Core::registerProviderExtensionKey($extensionKeyLowercaseUnderscored);
```

Fluid Pages will then look for template paths in `plugin.tx_thatext.view` - which is already fully compatible with standard Controller paths. In other words, to make any Extbase extension a provider of page templates, simply add a PageController which subclasses Fluid Pages' AbstractPageController and add the registration in ext_tables.php - and you're done, ready to use your PageController exactly like you would use any other Extbase controller with one added convention: one page template selection equals one controller action. Templates are still detected based on files in the path but now, each template in addition requires a corresponding Controller action.
[BUGFIX] Add missing consideration of native View paths

This fixes an issue with an invalid resulting array when retrieving global (indexed by extension key) page template configurations. After this, native paths for extensions registered through PHP also get considered by the code in question.
Merge pull request #23 from NamelessCoder/controllers

[FEATURE] Allow provider extensions to be registered using PHP
[FEATURE] Internal cache in ConfigurationService
[TASK] Retrieve "stored variable" cache by stricter key

This takes into consideration which variable is requested (in any Flux extension, this would be "storage" so no impact there), the paths (these could change dynamically in a ConfigurationProvider on the same page, i.e. in multiple content elements using the same ConfigurationProvider and should prevent some undesired reuse) and finally the section name that contains the variable to retrieve (again in almost all cases would be "Configuration" but also could be dynamically set by ConfigurationProviders).
[TASK] Use existing internal cache in PageService for template configurations

Stores the selected template and sub-template for a page by uid, saving multiple executions of root line retrieval and work space overlays.
[TASK] Internally cache root line affected FlexForm source in PageService
[TASK] When reading all registered extensions' registrations, cache each internally

This prepares the internal caches for any subsequent requests for individual extension's configurations.
Merge pull request #26 from NamelessCoder/caches

[TASK] Improve performance through internal caches
[BUGFIX] Fix case of class name used in PageSelector
[TASK] Use FlexForm Service from Flux to getStoredVariable