Add Runtime project and tests

[tracyboehrer]

Note that the warning for missing code comments has been disabled. Another issues has been opened to address that.

[EricDahlvang]

This is a phenomenal amount of work, with great improvements to the sdk's support of the composer experience!

Mostly, my comments are regarding TODOs and missing documentation or comments. I didn't look through the tests. I'm not sure some of these files are 'SDK type' files, but the overall direction of this PR looks like it will help alleviate many pain points with Composer/SDK integration.

[EricDahlvang]

Please describe with a comment with there's two registrations here.

[EricDahlvang]

comments.

Is this necessary? it is an empty interface. interfaces are hard to extend in a versioning system within c#. has that been considered here?

[peterinnesmsft]

Documentation added in latest commit. Will evaluate the necessity in another pass tomorrow.

[tracyboehrer]

On a related note: Is this Provider/Builder/Extensions framework something we would ever expect devs to extend or modify? Or is this an implementation detail of Runtime? I am having a hard time imagining a case where they would need to. The "public" portion of this is the runtime.json, and all this simply loads that in a platform specific way.

[peterinnesmsft]

The intention is that developers can implement custom Providers and Builders that can be registered as part of our extensibility story and ultimately incorporated via the standard runtime configuration mechanisms (i.e. runtime.json, for now).

The intention behind this is to ensure that the specified provider in the JSON configuration is indeed one intended to register IStorage and related/dependent services with IServiceCollection. I'm not having any immediate thoughts of how else to enforce this constraint outside of an interface without it becoming further convoluted. Open to suggestions, but I think for now I would say this is needed.

[tracyboehrer]

While allowing the developer to extend this is desirable long term, it's not a requirement in R12/13. Given the controversial nature of Providers/Builders, it should be marked internal to allow it time to bake and simplify. Since we are also building other extensibility stories on this (Custom Actions, OnTurnError, etc...), this isn't easily simplified, changed, or eliminated. This will also allow us the space and time to develop additional collateral, like samples and docs, around this story.

[gabog]

First pass at reviewing this.

I checked general project structure and dependencies at this point. I'd like to understand what Builders and Providers do and what will the extensibility points are before reviewing the rest.

Some thoughts include:

1. Will the dev be able to change Azure services by something else?
2. Will the dev be able to change QnA and or LUIS by something else?
3. How will the dev register other cognitive services? (add image recognizer for example)
4. Will the dev be able to change the adapter and use a different one?
5. Will we let the dev change or swap telemetry?
6. Will they be able to use TeamsActivityHandler instance of ActivityHandler?

[tracyboehrer]

Deferring integration with SDK until later.