runtime: return delayed duration from runtime.Yield

[dt]

Given the frequency with which we expect callers to call Yield, it is
not feasible to expect them to record the current time before every call
just to detect how much time elapsed, if any, in the call, when most calls
are expected to be near-instantanious no-ops. Instead, if we want to track
how much time is spent in Yield, we need Yield itself to measure this when
and only when it internally takes the slow, non-noop path and return it to
its caller, so that these (relatively) more expensive clock reads can be
restricted to and only to its rare slow paths where it actually does yield.

[dt]

I found myself wanting to have CRDB code to reflect yield delays in metrics and perhaps even have otel tracing spans to showing (at least any non-trivial) yield delays, but timing every call is not an option, and we don't know until we call it if it'll be a slow call, so I concluded the only option is to have the runtime function itself return how long it elected to deschedule the caller. It feels a tiny bit weird, but if I tell myself it is explicitly a function for offering to be rescheduled until such a time as there is capacity to reschedule, then it doesn't seem that weird to return the amount by which we took the caller up on their offer. Ideally I'd rather not do this in runtime code, but I couldn't see an alternative that didn't put clock reads on the fast path (no yield until <100% utilization).