Provide appropriate suggestions for some of the discussed await syntaxes

[estebank]

Regardless of the final syntax selected for await, given the prevalence of prefix keyword in other languages, and the possibility of thinking it is a method, the parser should support these syntaxes and error with an appropriate targeted diagnostic. Furthermore, should the field or method syntax were to be chosen, we should have reasonable behavior with explanations when accidentally using await when trying to access a field or call a similar method both inside and outside of async blocks.

[estebank]

Some of the cases to have tests for:

async fn foo() {
    let _ = await bar();
}
async fn foo() {
    let _ = await? bar();
}
async fn foo() {
    let _ = await bar()?;
}
async fn foo() {
    let _ = (await bar())?;
}
async fn foo() {
    let _ = bar().await();
}
async fn foo() {
    let _ = bar().await()?;
}
async fn foo() {
    let _ = bar().await;
}
async fn foo() {
    let _ = bar().await?;
}
fn foo() {
    let _ = await bar();
}
fn foo() {
    let _ = await? bar();
}
fn foo() {
    let _ = await bar()?;
}
fn foo() {
    let _ = (await bar())?;
}
fn foo() {
    let _ = bar().await();
}
fn foo() {
    let _ = bar().await()?;
}
fn foo() {
    let _ = bar().await;
}
fn foo() {
    let _ = bar().await?;
}

And we should have structs that have both similar method and field names, including r#await.

[Centril]

the parser should support these syntaxes and error with an appropriate targeted diagnostic

As long as you make sure that this doesn't stabilize the syntax (i.e. you need to account for macros) then I think this is a good idea.

[estebank]

cc #60586