Make pulumi.runtime.invoke synchronous.

[pgavlin]

These changes make the pulumi.runtime.invoke function invokable in a
synchronous manner. Because this function still needs to perform
asynchronous work under the covers--namely awaiting a provider URN and
ID if a provider instance is present in the InvokeOptions--this
requires some creativity. This creativity comes in the form of a helper
function, _sync_await, that performs a logical yield from the
currently running event, manually runs the event loop until the given
future completes, performs a logical resume back to the
currently executing event, and returns the result of the future.

The code in _sync_await is a bit scary, as it relies upon knowledge of
(and functions in) the internals of the asyncio package. The necessary
work performed in this function was derived from the implementations of
task_step (which pointed out the need to call _{enter,leave}_task)
and BaseEventLoop.run_forever (which illustrated how the event loop is
pumped). In addition to potential breaking changes to these internals,
the code may not work if a user has provided an alternative implementation
for EventLoop. That said, the code is a close enough copy of
BaseEventLoop.run_forever that it should be a reasonable solution.

[pgavlin]

CI failure was in the engine events perf test. Restarting.

[ellismg]

LGTM.

This is some pretty cool stuff, Pat.

[AstraLuma]

Because inner event loops are fun! (GTK's loop does the same thing.)

Yeah, the only reason this is ok is because pulumi controls the calling context and therefor what loop is used. If you wanted to support, say, uvloop, I would want to go on a spike and see what loops would be ok with this.

For the record, the way ASGI deals with sync/async context crossing is with multi-threading.