Fixes #1661 - Make IDocumentFilter async compatible

[schehlmj]

This is my take on the fix for this. Rather than extending IDocumentFilter, I created a new IDocumentAsyncFilter that is configured separately. I chosen to name IDocumentAsyncFilter to help make it clearer for developers. It continues to use a method named "Apply" like other filters, and since they Type itself makes it clear that it is for Async, I did not name the method "ApplyAsync". In cases where GetSwaggerAsync() is called, the IDocumentFilters will run first and then the IDocumentAsyncFilters. For GetSwagger(), only the IDocumentFilters are run. If IDocumentAsyncFilters are configured, it will throw an exception stating to use GetSwaggerAsync() instead.

I had also considered just extending the IDocumentFilter to interface to have an async ApplyAsync() method with a default implementation, but that was not possible with the targeted runtimes.

[schehlmj]

The check failing is:
Invoke-WebRequest "https://dot.net/v1/dotnet-install.ps1" -OutFile "./dotnet-install.ps1"
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.

I am not sure how to have it try again.

[martincostello]

Thanks for contributing - if you'd like to continue with this pull request, please rebase against the default branch to pick up our new CI.

[mauve]

I rebased and added support for the other filters in this PR: #2938

[martincostello]

I'm going to close this in favour of #2938. Thanks for the initial work on this @schehlmj.