ESLint rule for non-nested first await

[michaelfig]

This relaxes the restrictions imposed by @jessie.js/no-nested-await so that only the first await needs to be non-nested.

Also add some unit tests to better track the rule in the future.

[turadg]

I didn't fully step through the detection logic. I'm confident in its correctness from the test cases but I don't know if there's a more performant implementation.

Will approve after test cases are well organized.

[gibson042]

The part above this looks unnecessarily opaque to me. Can it be simplified and/or explained (e.g., "we allow await …; expression statements and identifierName = await …; assignments, but not update-assignment like identifierName += await …; or nesting in other structures such as array/object literals or argument lists")?

[michaelfig]

I've added a comment explaining this function's allowlist.

[turadg]

I find the logic suggestions Richard made easier to follow. I'll approve after those are resolved.

[turadg]

I appreciate the comment. Especially on subtlyBalanced in the other file. What the comment here says may be obvious if the names were mapped to this "smart enough" aspect:

Suggested change

	valid: clearlyBalanced,
	// `no-nested-await` is not smart enough to ignore subtle code that is
	// actually balanced. We test that it fails these cases.
	invalid: [...clearlyUnbalanced, ...subtlyBalanced].map(example => ({
	valid: trueValid,
	invalid: [...trueInvalid, ...falseInvalid].map(example => ({

[michaelfig]

I like clearly* vs subtly*, but I agree that *Balanced vs. *Unbalanced should be *Valid vs. *Invalid.

[turadg]

🎉

Excited to see the overzealous warnings in agoric-sdk go away :)