Keyword await should be able to await all operations pipelined

[Matesax]

As I am vastly using Fluent API and similar designs, I find intrusive this need to separate each method call into mid Task result. Why can await simply unpack all Task results within single pipeline? Similarly, it would be nice to use await automatically to an explicit Type association. I see no need to an explicitly unpack Task result when associating specific non-Task variable/argument. Because there is no reason for the single-resulting method to generate billion errors once switched async. (Only for me to be the monkey that needs to use billion await usages, where Task is already associated with E variable.) It would also be great to allow await instead async in methods. It would erase the need for void async methods, which are undesired. Unlike async methods, await decorated method should be standardly synced method with ability to auto-await mechanism. That way, unlike void methods, we would still know that it is really async-done method, but it is automatically awaited once used. Meaning that language would know to which Task context to associate this method during built time. (It can be internally still processed as async, just it wouldn't produce errors if left unawaited and it would allow sync usage. The key is a huge reduction of await chain.)

await FirstChainAsync().SecondChainAsync().ThirdChainAsync();
int ddd = IntResultAsync(); // Automatical await.

await void SyncedMethod()
{
await MethodAsync();
}

void SyncMethod()
{
SyncedMethod(); // We know to actually await here, obviously it would create blocking waiting. Deadlocks are still on the creator of async methods.
}

[HaloFour]

#827 (reply in thread)

#74
#96
#4076