Glimpse v2 - Reworked script tag generation and injection

This is a suggestion / first draft / solution :wink: for #791 

This removes the hacky approach inside the GlimpseMiddleware regarding generating and injecting the Glimpse client script tags.

Approach details:

- The `IRequestResponseAdapters` exposing the outputstream as well as the Content-Encoding (beware for OWIN there is no such property and defaults to UTF8 as it was in the hacky approach)

- The `PreBodyTagInjectionStream` is now wrapping the initial output stream as from `BeginRequest` (this might solve compression issues we had before, but to be tested)

- There is now a `ScriptTagsProvider` defined on the `IGlimpseRequestContext` which has a method `DetermineScriptTags` which will be used by the Glimpse Client controls and also by the `PreBodyTagInjectionStream`. This provider will use a delegate to decide whether or not it should generate the script tags when somebody wants them). This delegate will be provided by the `IGlimpseRequestContext` and will decide based on the `CurrentRuntimePolicy` and the `RuntimePolicyDeterminator` which is used by the `GlimpseRuntime` as well. The difference here is that the result of this determined runtime policy will not be assigned to the `CurrentRuntimePolicy` (at least that is the case for now)

- There was a need for the separate `ScriptTagsProvider` as relying only on the `GlimpseRequestContextHandle` from within the `PreBodyTagInjectionStream` would fail due to the different moments on which the `PreBodyTagInjectionStream` is actually used. In short: with the `GlimpseMiddleware` the tags will be generated in between `BeginRequest` and `EndRequest` while in the ASP.NET eventmodel, the `EndRequest` will already have executed when using the _filter_ approach, and since the `EndRequest` does a cleanup of the handle. The previous approach would render the scripts and attach the injection stream on `EndRequest`, hence bypassing this issue.

- Some additional comments will be added to the different changes that will illustrate the remarks made here
> What do you think?

We still need to be able to write headers/cookies for ajax and non-HTML responses.

I'm thinking we should move towards a single runtime policy execution (at begin request) and simplify that model. We've gone over both of these points before though. I like doing all of this in GitHub, but I think in this case it may be better to hash out a solution on Skype. 

Got any time on Aug 6th to chat?