Run integration tests conditionally

[JuanAr]

Included compilation directive and [Ignore] attribute to Integration Test classes to make them disabled by default. They run only when explicitly define the RUNINTEGRATIONTESTS compilation constant.
Integration tests will be shown as _ Skipped_ in the Test explorer with the message: These integration tests run only when RUNINTEGRATIONTESTS is defined.

#if !RUNINTEGRATIONTESTS
    [Ignore("These integration tests run only when RUNINTEGRATIONTESTS is defined")]
#endif

[JuanAr]

@cleemullins By merging this PR all integration tests won't run until the RUNINTEGRATIONTESTS compilation constant is included in the MS Build command line.
Alternatively, we can include the compilation constant in the build target configuration (e.g. we can configure the unit test project for the Release configuration)

[JuanAr]

We also moved all integration tests accessing network services to a new Microsoft.Bot.Builder.IntegrationTests project. Here we moved/copied tests classes from to categories:

1. We copied those integration tests that can use the mock HttpMessageHandler approach. This way, the two versions of the tests are available: Unit tests and Integration tests.
2. We moved those integration tests that are not suitable for mock. They will only exist in the IntegrationTests project.

[johnataylor]

only question is - does this include the extra build target referred to in the comment?
(its pretty sad that we have to use a macro to control the test framework - anyhow great to have the capability)

[JuanAr]

@johnataylor The compilation symbol/constant is configured in the new Microsoft.Bot.Builder.IntegrationTests.csproj project only for the Release configuration. Alternatively, you can temporarily add the RUNINTEGRATIONTESTS constant in the project properties page.

Yes, it is included, but take into account it is not a new Target. https://github.com/Microsoft/botbuilder-dotnet/pull/765/files#diff-dfa2c0caf486505728526f3e1095a104R10
And yes, code is a bit dirty with those conditional compilation directives. on the other hand, it seems very clear what those 3 lines are meant to.

[johnataylor]

@JuanAr can we close this now?

[JuanAr]

@johnataylor I think we should revisit the original objective for this PR.
Initially, the idea was to be able for users to just clone the repo and run all unit tests disconnected from external services while also having the option to run integration tests against the real services. This PR achieved the latest.

However, while developing mocks we implemented them in a way that, instead of two separated versions of tests (unit & integration tests), the same test uses a flag to conditionally hit the mocks or the external service. This might be a much better approach because it avoids having duplicated tests.
We already added issue #826 to use HttpRecorder to achieve this, if we agree we can close this PR without merging and take #826 as a replacement.

Let us know what you think.

[JuanAr]

Closing this obsolete PR since the approach used in tested changed to an hybrid one.