feat(maitake): dequeue one task at a time in scheduler

[devsnek]

In order to allow stealing tasks from blocked cores, don't hold a Consumer for run_queue while polling.

I think as-is, this changes the documented behavior:

Only a single CPU core/thread may tick a given scheduler at a time. If another call to tick is in progress on a different core, this method will wait until that call to tick completes before ticking the scheduler.

and allows interleaving calls to tick. Is this a property worth maintaining? I think a lock could be introduced to do so if necessary.

[hawkw]

I think as-is, this changes the documented behavior:

Only a single CPU core/thread may tick a given scheduler at a time. If another call to tick is in progress on a different core, this method will wait until that call to tick completes before ticking the scheduler.

and allows interleaving calls to tick. Is this a property worth maintaining? I think a lock could be introduced to do so if necessary.

I don't think this property is necessarily worth maintaining, and it might be worth removing it from the documentation entirely after merging this change. The primary motivation for acquiring the consumer a single time was to avoid the overhead of re-acquiring the consumer every time a task was polled, not to enforce that a scheduler can only be ticked by one core at a time.

However, we might want to have the LocalScheduler and LocalStaticScheduler types continue to do the current behavior, since tasks spawned on those schedulers may be !Send and can therefore never be stolen. So, it might be nice for those schedulers to avoid multiple attempts to acquire the consumer. This isn't a blocker for this PR, and I think it would make the code somewhat more complex (since we would have separate tick methods for those schedulers, which we don't currently).