This commit removes some unnecessary calls to register components, 

as advised by StructureMap's JDMiller. This is with the aim of minimising difficult to debug issues at load, by reducing the amount of calls made to the SM container from Nancy.

The call to configure  has been completely removed from  as it is not needed.

The  method which is called per request does not need to register the current module type on the fly, and can just return it from the container and cast it to INancyModule, as "StructureMap can happily build a concrete type even if it's not explicitly registered as long as the StructureMap container can fill the the concrete type's dependencies."
@thecodejunkie @grumpydev 

This is the section I'm not sure about and would like some advice on if you've got time. My thinking was that the power to specify class lifetimes could be passed up to the relevant DI framework registration, rather than being enforced within here.

Looking at the [wiki] (https://github.com/NancyFx/Nancy/wiki/The-Application-Before%2C-After-and-OnError-pipelines#wiring-up-your-hooks) and at other DI Bootstrapper implementations (AutoFaq / Castle etc) it would seem this is added to enforce a distinction between "PerRequest" startups and "Application" startups, specifically to enable PerRequest IRequestStartups to be stored alongside a Request specific nested Container. 

Have I got this right? If so, I may need to revert this change, leaving the container.Configure() code in.