GH-43631: [C++] Add C++ implementation of Async C Data Interface

[zeroshade]

Rationale for this change

Building on #43632 which created the Async C Data Structures, this adds functions to bridge.h/bridge.cc to implement helpers for managing the Async C Data interfaces

What changes are included in this PR?

Two functions added to bridge.h:

1. CreateAsyncDeviceStreamHandler populates a ArrowAsyncDeviceStreamHandler and an Executor to provide a future that resolves to an AsyncRecordBatchGenerator to produce record batches as they are pushed asynchronously. The ArrowAsyncDeviceStreamHandler can then be passed to any asynchronous producer.
2. ExportAsyncRecordBatchReader takes a record batch generator and a schema, along with an ArrowAsyncDeviceStreamHandler to use for calling the callbacks to push data as it is available from the generator.

Are these changes tested?

Unit tests are added (currently only one test, more tests to be added)

Are there any user-facing changes?

No

• GitHub Issue: [Format][C] Add ArrowAsyncDeviceStreamHandler to C Data Interface #43631

[lidavidm]

Are we supposed to have a blocking call in consuming an AsyncGenerator?

[zeroshade]

I honestly couldn't figure out a better way around this to manage the backpressure from the calls to request. I'm open to suggestions for a better route here other than simply saying this should not be run on the main thread shrug

[lidavidm]

I guess this works for now

[lidavidm]

I suppose the way it "should" work is that we never call into the AsyncGenerator unless we have a pending request? But we'd then need to handle more of the control flow here ourselves

[paleolimbot]

I don't see anything out of place here and I checked that the documentation/interface makes sense to me (and it does!).

Not at all essential, but it might be worth marking these as experimental (e.g., so that it is less surprising if you have to update how the Executor works).

[zeroshade]

@bkietz I addressed your suggestions!

@paleolimbot I've updated the doc briefs to include EXPERIMENTAL:

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit aab7d81.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 8 possible false positives for unstable benchmarks that are known to sometimes produce them.