Add Scheduler trait

[tsoutsman]

Adds the Scheduler trait to task which can be used to dynamically switch between schedulers, akin to SELECT_NEXT_TASK_FUNC but with more functionality. Merges the runqueue_* and scheduler_* crates as a byproduct because now the state must be stored with policy.

The PR makes run queues (i.e. schedulers) more opaque by removing the ability to directly access a run queue. I think this is the way we want to go because it prevents bugs such as #1000. Realistically, users shouldn't have complete access over the run queue.

Also I'm not sure about the API for task::scheduler. I was thinking instead of the function variants (e.g. add_task add_task_to, add_task_to_current) to instead have something like

// Or some better name
pub enum SchedulerSpecifier {
    Any,
    Specific(CpuId),
    Current,
}

pub fn add_task(task: TaskRef, scheduler: SchedulerSpecifier) {
    // ...
}

but I'm also fine with the current API.

Depends on #1036.

[tsoutsman]

Forgot to add the single_simd_task_optimisation config blocks back. Will add that tomorrow.

[kevinaboos]

for this and the other impls of dump, i'd vote to change the signature to return an iterator over TaskRefs as Items rather than forcibly collect() it into a Vec. No need to eagerly collect if the caller is just going to iterate anyway.

Could also re-name it more accurately to something like task_iter, or a similar name of your choosing.

[tsoutsman]

We can't return an associated type because then the trait wouldn't be object safe.

Could also re-name it more accurately to something like task_iter, or a similar name of your choosing.

As I've stated above it can't return an iterator so I've renamed it to tasks because it returns a vec of the tasks in the run queue.

[kevinaboos]

Right, I didn't mean to suggest using an associated type like my old scheduler refactor design, but rather an impl Iterator<...>. But I just realized that I had only recently heard about RPITIT being supported in soon-to-come future versions of Rust, so I was mixing up the fact that RPITIT support is coming soon with the fact that it doesn't actually exist yet in the version of Rust we're pinned to.

[kevinaboos]

Actually it appears that it is already supported on nightly -- but we can save that for another PR.