Data.Common and SqlClient: considering adding an alternate version of GetFieldValueAsync<T>() that returns a ValueTask<T>

[divega]

Based on the the description of ValueTask<TResult> and the discussion at https://github.com/dotnet/corefx/issues/4708 it seems that GetFieldValueAsync<T>() (on DbDataReader and derived types) could use it to enable more efficient fine-grained async code.

Note that we haven't performed any measurements to try to understand the impact of this change, and that the higher level components we work on such as EF6 and EF Core currently would not take advantage of it, but we are creating this issue to have a chance to evaluate this improvement for other code that uses this ADO.NET API directly.

Also note that fine-grained async APIs that return Task<bool> (such as ReadAsync() and IsDBNullAsync()) may return cached Task<bool> instances to gain efficiency instead of adopting ValueTask<TResult>.

From my perspective, there are a couple of open issues if we decided to do this:

1. Naming of the new method: since there can't be yet another overload that only differs on the return type, and the "standard" name with just the Async suffix is taken.
2. Compatibility for providers: It seems desirable to offer a default implementation of the Task-based method that calls AsTask() on the ValueTask<TResult> instance returned by the new API, so that new providers don't need to implement the old Task<TResult> version of the API but instead only implement the more efficient ValueTask<TResult> version. It also seems good not to force existing providers to switch.

I am currently thinking that adding an optional interface with the new API could be a solution, but there are other disadvantages in that approach.

cc @stephentoub @YoungGah @saurabh500

[divega]

Closing in favor of https://github.com/dotnet/corefx/issues/27682.