Find a way to handle branch events in `async for`

[markshannon]

When instrumenting regular for loops, we instrument the FOR_ITER instruction as the LEFT branch and the POP_ITER instruction as the RIGHT branch.

This doesn't work for async for as it uses exceptions to exit the loop.
Raising an exception is the documented behavior for exiting a [async] generator, so we will still need to generate an event for the exception being raised, much as we do in INSTRUMENTED_END_FOR as well as the BRANCH events.

Linked PRs

• GH-128534: Instrument branches for async for loops. #130569
• GH-128534: Fix behavior of branch monitoring for async for #130847

[markshannon]

The bytecode for

async def foo(x):
    async for y in x:
        A

is

   1            RETURN_GENERATOR
                POP_TOP
        L1:     RESUME                   0

   2            LOAD_FAST                0 (x)
                GET_AITER
        L2:     GET_ANEXT
                LOAD_CONST               0 (None)
        L3:     SEND                     3 (to L6)
        L4:     YIELD_VALUE              1
        L5:     RESUME                   3
                JUMP_BACKWARD_NO_INTERRUPT 5 (to L3)
        L6:     END_SEND
        L7:     STORE_FAST               1 (y)

   3            LOAD_GLOBAL              0 (A)
                POP_TOP
                JUMP_BACKWARD           17 (to L2)

   2    L8:     CLEANUP_THROW
        L9:     JUMP_BACKWARD_NO_INTERRUPT 12 (to L6)
       L10:     END_ASYNC_FOR
                LOAD_CONST               0 (None)
                RETURN_VALUE

  --   L11:     CALL_INTRINSIC_1         3 (INTRINSIC_STOPITERATION_ERROR)
                RERAISE                  1
ExceptionTable:
  L1 to L2 -> L11 [0] lasti
  L2 to L4 -> L10 [1]
  L4 to L5 -> L8 [3]
  L5 to L7 -> L10 [1]
  L7 to L8 -> L11 [0] lasti
  L8 to L9 -> L10 [1]
  L10 to L11 -> L11 [0] lasti

One way to instrument this would be to add a NOT_TAKEN after the END_SEND or instrument the END_SEND for the LEFT branch, For the RIGHT branch we could instrument END_ASYNC_FOR.
This shouldn't prevent future specialization of async for as that would require splitting END_ASYNC_FOR into two instructions. We would then instrument the second.

[markshannon]

We still need to add these new branches to co_branches()