Ensure guest run is initialized when start_guest_run() returns

[oremanj]

Run a few ticks of the guest run synchronously within start_guest_run, so that global Trio operations such as current_time() and spawn_system_task() work as soon as start_guest_run returns (rather than at some indefinite point in the near future).

Motivating use case: allowing trio/asyncio integration beginning from asyncio mode to start up a Trio run and create a backing Trio task for an asyncio task that's about to enter Trio mode, all from a sync-colored context. The reverse (starting an asyncio guest run synchronously) is already supported by aioguest and is necessary to support sync-colored wrappers around asyncio-flavored async functions; that idiom is less common for Trio-flavored code, but it's still convenient to be able to treat both directions of transition in the same way, and it seems likely this PR could simplify other guest-mode wrappers as well.

[codecov]

Codecov Report

Merging #2696 (cc2d74a) into master (d3255a0) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2696   +/-   ##
=======================================
  Coverage   98.94%   98.94%           
=======================================
  Files         113      113           
  Lines       16851    16885   +34     
  Branches     3032     3036    +4     
=======================================
+ Hits        16673    16707   +34     
  Misses        123      123           
  Partials       55       55           

Files Changed	Coverage Δ
trio/_core/_run.py	99.44% <100.00%> (+<0.01%)	⬆️
trio/_core/_tests/test_guest_mode.py	99.68% <100.00%> (+0.02%)	⬆️

[A5rocks]

This looks sane and makes sense to me (though I have a couple bits I don't get, like next_send being different on Windows and non-Windows), but I really don't know how guest runs work or anything like that.

Probably wait for someone else to review!

[oremanj]

next_send is supposed to have a type that matches the return value of IOManager.get_events(). On Linux it's a list of events, while on Windows it's a count of events; the difference owes to low-level API arcana. We don't bother actually checking for I/O during these first few ticks because there shouldn't be any tasks that need it yet. I'll add a comment.

[A5rocks]

Well, hopefully someone with knowledge reviews this + #2700 in the near future! (Just bumping this :P )

[richardsheridan]

This PR has a typing "problem" in that it correctly sends None in the first pass through the loop, but the typing annotations don't seem to understand that that is required. I don't know enough about typing to fix that but since there are other typing problems on master, I'm just merging to get this fix in and bring #2700 up to date as well.