Refactor: Tidying of controller, improving user service interface and removing knowledge of post vars at authentication level

This PR contains no changes to the features of ZfcUser. It is just the start of some refactoring of the module.

This PR doesn't provide much improvement as it is just the very start of the process, I have issued it however to make sure I'm on track as I don't want to spend days/weeks doing a full  refactor then have it rejected.

What this refactor contains
====================
Tidying of controller actions
-----------------------------------
I've started tidying up the controller actions by breaking them up into protected methods.

Now the code in the actions are a much better representative of what is going on.

I still think there are some un-necessary setters and member variables for the forms.

Updated the Service\User interface
--------------------------------------------
register() previously took an array (the post data) as its parameter, which was ok but then it created a form object to validate it which seems a bit crazy. Having UserInterface typehinted as the parameter make it a much better defined interface.

I've also done the same for changeEmail() and changePassword().

As well as creating `ZfcUser\Service\UserInterface`

I have also injected the crypt object.

One cool thing about this is now someone can extend the User entity, Registration form and User mapper if they want to add extra fields to the user. There would be no need to extend the User service or hook events to do this now.

Removed knowledge of post variables further down the authentication process
---------------------------------------------------------------------------------------------------------------------
The current authentication method adds the `Request` object to the `AdapterChainEvent` then in `Authentication\Adapter\Db` the requested identity and crediential are fetch out of the post variables via the request.

I don't think there should be any knowledge of post variables this deep in the process there for I have now made it so that the post variables are fetched in the controller (maybe these should even come from the form object?) and then the are set as parameters in the `AdapterChainEvent` via `setAuthenticationParams()` which is then used in the `Authentication\Adapter\Db` class.

**Pros of this action**
* Removing knowledge of HTTP at the authentication level
* Easier for testing
* Looser coupling allowing for more extensibility

----------------------------------------

So these are just 2 things I have started on, I would very much like to push on further but I thought I'd issue this PR to get a go ahead or stop at this point.

I very much look forward to a response.