Add async APIs to push users aways from sync over async patterns

## Summary

A number of APIs in .NET Core are async aware and probably should have been in .NET Framework. However, when adapting the behavior of core behind the APIs framework had ends up with a number of sync over async patterns. We should provide a way forward here that will guide people to using async.

## Motivation and goals

We should provide async methods that end up calling into async pathways on .NET Core. Currently, this is handled either by invoking required async pathways in middleware or by calling `GetAwaiter().GetResult()`.

## In scope

This would ideally provide APIs that users on framework, core, and standard could all use. Depending on where things run, it would either be true async (i.e. on ASP.NET Core) or just return a completed task (i.e. on ASP.NET Framework).

Initial APIs identified:

- `HttpRequest.InputStream`
- `HttpResponse.End()`
- `HttpResponse.TransmitFile`
- `HttpResponse.SendFile`

probably some more (especially those that rely on any of these APIs).

## Out of scope

- No plans to make ASP.NET Framework more async aware

## Risks / unknowns

- Developers may think this is making ASP.NET Framework async aware

## Examples

Currently:

```csharp
public void SomeFunc(HttpResponse response)
{
response.TransmitFile("some-path");
}
```

after:

```csharp
public async Task SomeFunc(HttpResponse response)
{
response.TransmitFileAsync("some-path");
}
```

## Design considerations

- A number of these APIs are also exposed on the `*Base` and `*Wrapper` types. Would need to identify how to handle those
- Since we're type forwarding to `System.Web.dll` on framework, we will probably want to provide any async functionality as extension methods that would forward to the non-async on framework while using actual async behavior on ASP.NET Core