fix potential nil deref in waiter path matcher

[lucix-aws]

Fixes #562

Basically, whenever you have a sub-expression (visit the left, then pass the result to the right), you need to check whether the left can be nil. If it can, then the generated code has to check for that, pre-declaring a variable for the result of the right, which the generated RHS code would then store the result in if it passes the nil check.

Take a look at the updated tests for some examples.

Verified that all downstream waiters in aws-sdk-go-v2 compile with this change (including the ones we haven't enabled generated path matchers for yet).

[Madrigal]

Food for thought. #562 describes the following JMESPath expression

ImportSnapshotTasks[].SnapshotTaskDetail.Status

Even with the updated code, we're checking that we generate the right code once we updated the generator, but we wouldn't have caught that this (or a different) expression caused a nil panic.
I suspect this could be hard to test, since we would have to actually run the code that we generate, but curious to hear you thoughts if we could improve how we test JMESPath for the new waiters

[lucix-aws]

Yeah, I'm looking at that in the background. Basically looking at generating something like what we have in internal/protocoltest in the SDK, but for waiters - we'd write some dummy model that has all the waiters we want to test, and then handwrite tests for them. I believe Kotlin does something like this today.