Add an async/await pattern test suite and fix the await operand conversions it found

[christophwille]

Adds a pretty/correctness test suite for ExpressionBuilder.VisitAwait, and fixes the await-operand conversions the suite turned up.

The conversion in front of an await operand

VisitAwait used to finish with ConvertTo(expectedType, allowImplicitConversion: true). There is no target type the C# compiler could convert an await operand to -- the await pattern is resolved by member lookup on the operand itself -- so any conversion that is merely implicit was being dropped, taking load-bearing casts with it. That is CS1929 for an explicit interface implementation, CS4001 for await (Task)null, and pointer-shaped nonsense for an in-receiver extension awaiter.

The replacement asks the question that actually decides it: does the operand, written plainly, bind the same GetAwaiter the IL calls (CallBuilder.CheckSimpleCall)? If not, the cast stays and is emitted explicitly.

That needs one wrinkle for boxing. A struct receiver reaching an extension GetAwaiter declared on an interface is boxed, so the translated operand is typed object and the lookup finds nothing -- which would put a redundant (IAwaitableMarker) in front of every such await. C# boxes an await operand implicitly, so the box need not survive; the lookup therefore looks through the boxing ConversionResolveResult, and the box is only detached once the answer is known. UnwrapChild mutates the AST, so running it speculatively leaves a cast with no child behind and the whole method falls back to printing its raw state machine.

The Box stays in the ILAst either way, so Await's argument still matches the stored GetAwaiterMethod.

Tests

• TestCases/Pretty/AsyncAwaitPatterns.cs -- await contexts (statement position, operators, member access, try/finally, await using/await foreach, async iterators), operand shapes (ternary, coalesce, cast, null literal, field/property/indexer, struct element), and receiver shapes (instance, inherited, interface, explicit interface implementation, user-defined conversion, extension on class/struct/primitive/delegate/tuple/in receiver, generic, ConfigureAwait). The shapes where the cast in front of the operand is load-bearing live here too, so they stay covered as regression tests.
• TestCases/Correctness/AsyncAwaitPatterns.cs -- what the awaits have to mean: copy semantics of struct awaitables (mutable field vs. readonly field vs. property) and evaluation order around the suspension point.

Known-bad shapes filed instead of pinned

Three await shapes still decompile to code that does not compile. They are unrelated to the operand conversion and have no correct output to pin yet, so they are tracked rather than committed as a red test:

• await on a type parameter with an interface constraint drops the operand (LdObjIfRef not supported) #4017 -- await on a type parameter with an interface constraint drops the operand (LdObjIfRef unsupported)
• await in a static dynamic call materializes the call site's typeof marker as the receiver #4018 -- await in a static dynamic call materializes the call site's typeof marker as the receiver
• with expression containing an await leaves the raw <Clone>$ call in the output #4019 -- with expression containing an await leaves the raw <Clone>$ call in the output

default(Task) was also on that list and is not a defect: it compiles to the same ldnull as (Task)null, so the two are indistinguishable in IL and the cast is a correct decompilation.