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
the reason why I said that was because putting a `@Html.GlimpseClient()` is something that must be available for each request. Not everybody is using or can use a masterpage for each page it has, which means that the `@Html.GlimpseClient()` might be spread around while the initial reason to have the `@Html.GlimpseClient()` was to handle the cases where no `</body>` tag was found. So I am a bit reluctant to add a global setting indicating whether or not to use the injectionstream because it might lead to inconsistent behavior if users are not sufficiently aware they need to add the GlimpseClient explicitly for every possible request.

Now from a performance point of view, that should be negligible as if we don't need to render, we simply forward the call to the original outputstream. True there is an initial penalty to check whether or not we should inject or not, but that call will be made anyway at EndRequest (if we only make the check once instead of twice now)