Implement `AsyncMethodBuilder` for `CommandTask<T>` to refactor some code

[Tyrrrz]

Details

Currently, some parts of CliWrap's internal code use the following patterns to build upon CommandTask<T>:

https://github.com/Tyrrrz/CliWrap/blob/b956aaf4934ad735b3cad9d1d9d0422b11e1287c/CliWrap/Buffered/BufferedCommandExtensions.cs#L46-L76

https://github.com/Tyrrrz/CliWrap/blob/b956aaf4934ad735b3cad9d1d9d0422b11e1287c/CliWrap/EventStream/PullEventStreamCommandExtensions.cs#L65

This is because we can't use async/await in methods returning CommandTask<T> because C# compiler doesn't know how to construct instances of CommandTask<T>.

We should be able to resolve this by implementing a custom AsyncMethodBuilder for CommandTask<T>. Some resources on this topic:

• https://devblogs.microsoft.com/premier-developer/extending-the-async-methods-in-c/
• http://blog.i3arnon.com/2016/07/25/arbitrary-async-returns/
• https://gist.github.com/Horusiath/401ed16563dd442980de681d384f25b9

The method builder should probably be internal to avoid introducing unnecessary liabilities. The end user is unlikely to define methods that return CommandTask<T> themselves. If this issue arises in the future, we can address it then.

[Tyrrrz]

Now that I think about it, this might not be possible to implement. That's because CommandTask<T> isn't really an async container in the same general sense as Task<T>.

More specifically, a method with async CommandTask<T> signature would only work if:

• The method starts with await on another method returning CommandTask<T> (probably Command.ExecuteAsync()). Otherwise, we have nowhere to get the ProcessId value from.
• The method should not await more than one CommandTask<T> method. Otherwise, we don't know which value of ProcessId to use on the resulting task.

I doubt C# compiler can enforce these criteria for us. Perhaps, it's more practical to continue using the existing Select()/Bind() abstractions.

[Tyrrrz]

Decided it's not really worth it