We now mark some DeclRefExpr and LookupExprs as implicitly async
during typechecking, depending on whether they appear in a context
that is only performing a read / get operation, and whether they
are cross-actor operations.
also resolves rdar://72403401 by improving the error messages
(no more vague "'await' in async context" when its clearly a call!)
The `try await` ordering is both easier to read and indicates the order
of operations better, because the suspension point occurs first and
then one can observe a thrown error.
Currently, we don't have a fix-it to insert 'async', so I've marked those places
as not expecting a fix-it, until someone goes and implements that (rdar://72313654)
when the call in an autoclosure is async and throwing, if the call is covered by a try! or try?,
the existing check that used Context::isAutoClosure was too pessimistic, saying it is not an
autoclosure because errors are handled within it. For the error message about a missing await,
we don't care about whether the throwing-ness was handled.