Finish lazy stack trace support by implementing async* support and fixing line numbers

[mkustermann]

The cl/122644 adds the --lazy-async-stacks. After the CL lands we still have to do two follow up changes

• Ensure we have correct line numbers for async frames
• Implement support for async* functions
• Investigate why the test fails on dartk-optcounter-linux-release-x64
• Start rolling out the lazy stack trace support

The support for async* should be analogous to async:

• Assign fixed context index to _AsyncStarStreamController :controller
• Add pragma("vm:entry-point") annotations to used fields
• In stack trace generation code, follow the metadata to find the listener

The metadata should be available via:

_AsyncStarStreamController<T>
    StreamController<T> controller
      _StreamController _varData (if `_state == _STATE_SUBSCRIBED`)
          _ControllerSubscription<T>/_BufferingStreamSubscription.<T>_onData
             _StreamIterator._onData (validate it's a _StreamIterator._onData tearoff, need to get "this" from tearoff context)
                 _StreamIterator._stateData (if is _Future)
                      _Future.... (the regular code to find awaiter from _Future)

/cc @mraleph

Note: This is a follow-up to #37668

As for the dartk-optcounter-linux-release-x64 failures:

Testing locally I see dartk-optcounter-linux-*-x64 failing vm/dart/causal_stacks/async_throws_stack_test tests with --causal-async-stacks.
The stacktraces incorrect labels sync-async frames async-async and inserts bogus <asynchronous suspension>.

My understanding of what is happening is that the optimizing causes certain frames to disappear - specifically I see a diff optcounter and non-optcounter showing _Closure.call and sometimes even _AsyncAwaitCompleter.start disappearing.
This causes issues for stack_trace.h:CheckAndSkipAsync(..) which checks for these frames to determine if we're running sync-async.
If neither of these frames are seen we're (incorrectly) assumed to be async-async.