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
this is quite important (also in the Flush below)

if there is no Html to be written, then we should not try to parse the contents as UTF8 strings etc.. because the stream can be binary (images etc...)

this check might change as well into something clearer instead of checking for the html snippet content. 
It is related to the different funcs above, and by grouping them in one thing that is lazy loaded, it will be cleaner