[feature]: `spawn_blocking` variant for `future_into_py`

[winstxnhdw]

Currently, future_into_py uses spawn but I would like to use future_into_py with some of my light CPU-bound workloads, and I think spawn_blocking would be the more appropriate procedure here to reduce the chance of thread starvation.

[davidhewitt]

Why not just do future_into_py(spawn_blocking(blocking_code))?

[winstxnhdw]

Doesn't future_into_py already do spawn? I might be wrong but if I did that, would it not create more threads than necessary?

[davidhewitt]

spawn will just create a new task on the existing runtime threads, it doesn't create more threads. Wrapping the future created by spawn_blocking with a new task (via spawn) should have very little cost.