[Reviewer: Graeme][From: Alex] HttpStack changes for sto809

Hi Graeme,

Please can you review my `HttpStack` changes for sto809. This covers:

* Re-factoring the API so that there are per-URL "controllers". Per-request "handlers" are optional and only used if the controller requires them.
* Equivalent re factoring to the `Diameter::Stack` API. 
* Adding a thread pool that can be wrapped around a controller so it is executed in a worker thread from the pool, rather than an `HttpStack` transport thread. 
* Re-factoring SAS logging in the `HttpStack` so that controller can supply their own logging callbacks. 

Two changes from the design you reviewed:

* I realised that have separate `ControllerInterface` and `BaseController` classes was unnecessarily. The latter just contains default implementations of methods on the former, and these could just be moved into `ControllerInterface` 
* I've handed omission of the HTTP body in SAS logs by logging the body as "<Present but not logged>" (which was option 2. from the design). My preferred option (option 3.) made the decoder unintelligible. 

Note we recently agreed as a team that the "Controller"/"Handler" naming scheme should instead be "Handler" (for the per-URL object) and "Task" (for the per-request object). I haven't made this change yet - for one thing it would made the review impossible to understand, and also I may have to defer it due to time constraints. 

This code has been tested as part of the homestead UTs (like the `HttpStack` UTs)


Should handler_callback_fn and _callback_handler now be called controller_callback_fn and _callback_controller? Similarly below for fallback_handler_callback_fn and _callback_fallback_handler. I may just be getting confused with handlers and controllers here. Also for bonus points you're going to change these again so...