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
I'm sorry, but I'll have to disappoint you again...

The flooding the log I was talking about there, was related to writing down the headers and cookies, which are now all put in a try/catch block and logged on failure... and unfortunately that will still be the case.

Basically we need to think hard about how we are going to deal with writing that one `Glimpse-RequestID` header that will be an issue and that one cookie `glimpseId` which are both set inside the `GlimpseRuntime.EndRequest`

The problem is not the ASP.NET case (although as you had to fix, issue might still occur there as well...) but more the OWIN and Nancy and the like cases, where there is no way for us to know when headers were actually sent down or even better before they are being sent down...

The `ScriptTagsInjectionStream` only handles the body part of the response, not the headers etc... so we can't use that one to piggy bag on it.

So basically I'm more and more convinced that we need to go for a `head` or post `<body>` injection like I mentioned [here](https://github.com/Glimpse/Glimpse/issues/791#issuecomment-42249998) once. 

Some advantages are
- it is easier to locate the first opening `<head>` or `<body>` tag and inject a script right after it
- no need to buffer everything else and parse the content to look for a `</body>` tag, which will be better for performance reasons..
- no need to write headers or cookies during the request itself, because the script we will inject will take care of that part (see the How in a few moments :wink: )
- the latest changes made will make sure we only inject the script when the script would be injected anyway, as all the `IRuntimePolicy` for `EndRequest` were consulted on first write to the stream..., which was one of the earlier remarks...

How do we do that, what would be injected then?
- I would not inject the current script tags but a bootstrapper script tag (I know, a `<script>` tag that will block the loading of the page as a request will be made synchronously, although that could be solved by adding the `async` attribute for newer browsers - IE10+ and the rest basically)
- It needs to be a `<script>` tag because otherwise we might have issues to remain CSP compliant, so no inline code
- That script tag would load the Glimpse Client Bootstrap resource passing in the `GlimpseRequestId` as a parameter
- That resource will then send down a script that will add the current script tags of Glimpse dynamically by inserting those script tags before the `</body>` tag when the DOM is finished loading (to make sure the `</body>` tag is available). That way those script tags will still be loaded fairly late in the rendering process of the page and with the `async` attribute the overall performance impact on the rendering client side should be minimal (and might actually be faster due to less code being executed server side inside the injection stream)
- using the explicit `Glimpse client controls` would also result in that BootStrapper scripttag to be written
- the `BootStrapper` Glimpse client resource would then write the necessary headers and cookies if needed, hence no reason to write cookies or headers when injecting the glimpse client during the monitored request, hence no more try/catch needed, hence no more log bashing (and potential issues with the Glimpse client expecting to have those headers/cookies to its disposal)

What do you think? Might that be an approach to solve those issues I talked about in #825 and #791 and it would address [your remark below](https://github.com/Glimpse/Glimpse/pull/810/files#r15298703) as well ?