Make TelemetryClient service request-scoped instead of application-scoped

[olegsych]

We currently scope TelemetryClient to the entire application, which can lead to hard to diagnose problems when developers change its request-specific properties, like TelemetryClient.Context.Session.Id. I think the TelemetryClient service should be request-scoped and rely on the container to inject the application-scoped TelemetryConfiguration (see issue #10).

cc: @SergKanz , @abaranch, @upendras, @sergei-nikitin

[SergeyKanzhelev]

It definitely makes sense with the "new" approach we will discuss. With the current approach we need to have a place to set InstrumentationKey
https://github.com/Microsoft/AppInsights-aspnetv5/wiki/Configure#code-based-approach
and set global properties:
https://github.com/Microsoft/AppInsights-aspnetv5/wiki/Configure#add-application-level-context-properties

I don't see alternative (unless we will ask to use TelemetryConfiguration.Active very explicitly)

[olegsych]

The instrumentation key is easy - you can set it on the application scoped TelemetryConfiguration (see #10). Other application scoped properties like ComponentContext.Version can be set with a context initializer, perhaps hidden by a nice extension method.

The reason I believe we should not use the Active singleton is because it wont work in multitenant apps like Orchard. Plus we don't know how many RequestDelegate pipelines per AppDomain there could be.

[SergeyKanzhelev]

Oh, you propose to add TelemetryConfiguration to service provider as singleton instead. Sounds reasonable for me.

[olegsych]

Done.