Support for Task-based layer

Logging this as a placeholder - it's more of a nice to have than something that I'd be personally investing the time to execute on at present.

In Equinox and Propulsion, I've recently transitioned to task from async. This means Equinox.DynamoStore has a layer which is all task and/or TaskSeq stuff, which then needs to call out to FSharp.AWS.DynamoDB. Aside from the perf cost, the layers of redundant mapping also make it harder to diagnose/reason about exception mappings and the like.

If one was building this lib today, arguably one would build it primarily with task in the first instance.

For Equinox's purposes, the ideal would be to introduce a layer that exposes a Task-based API, and then layer the existing one over that. I suspect that over time there will be a growing number of usage scenarios where the caller is task-based.

One concern would be that realistically one would need to expose a ?ct (or perhaps a non-optional CancellationToken arg) absolutely everywhere ... unless one waits for a long term cancellableTask impl to gain currency).

Start by reviewing the existing async API and how Equinox.DynamoStore calls FSharp.AWS.DynamoDB. Define the Task-based layer, decide how CancellationToken arguments should be exposed, and ensure the existing API can be layered over it; the issue names no files or tests.