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
since we are creating the `InjectionStream` at `BeginRequest` we must delay the resolving of the html snippet, but also of the encoding used etc... because they will change between the `BeginRequest` and the first byte being written to the stream, so they are lazy loaded (hence the issue if this lazy evaluation occurs outside the `GlimpseRequestContext`