Add SqlCommand.Table type for ResultType.DataReader and ExecuteReader for ResultType.DataTable

Description

I'd like to be able to track the progress of loading a datatable, the library allows to return DataReader but then you are on your own as you don't have a typed table populate.

The DataTable data structure is very valuable / efficient and interacts with IDataReader through Load method, I believe bridging the gap is a natural improvement.

I've considered exposing a LoadDataTable method that would take an existing table but such design approach would need more time and consideration as to fit well with the principles of this library.

The main cons I see is people using DataTable will be able to call ExecuteReader and not dispose the reader, they couldn't shoot themselves that way before.

The pros is that with this, people have ability to populate their tables in background while still being able to keep track of loading progress, this is the simplest solution to enable clients to do this with type safety properties of this library.

The work around right now is to define two commands with same command text.

Sample Code

with proposed change this would compile:

type Command1 = SqlCommandProvider<"select ... ", connection, ResultType = ResultType.DataTable>

do
    use command : Command1 = ...
    use reader command.ExecuteReader(parameters)
    let table = Command1.Table()
    table.Load reader

type Command2 = SqlCommandProvider<"select ... ", connection, ResultType = ResultType.DataReader>

do
    use command : Command2 = ...
    use reader command.ExecuteReader(parameters)
    let table = Command2.Table()
    table.Load reader

@dmitry-a-morozov, @dsevastianov, @vasily-kirichenko looking for your feedback if you feel this is ok? or any other user that would be happy with this feature / suggestions for the changes / matching the use case.

Thanks for the feedback.

Start by reviewing the existing SqlCommandProvider handling for ResultType.DataReader and ResultType.DataTable, then compare the proposed ExecuteReader and Table APIs in the sample code. The design is complete when the supported API is agreed, its disposal and progress-tracking behavior is defined, and coverage verifies both result types.