Move scheduling functionality into task; add Scheduler policy tra…

…it (#1035)

* Add the `Scheduler` trait, which represents a scheduler policy.
  * By default, there is one instance of a `Scheduler` policy per CPU.
  * Support dynamically registering and switching between
    different scheduler policies on a per-CPU basis.
  * Because this is now defined in the `task` crate instead of in the
    `scheduler` crate, the `task` crate can now access all functionality
    provided by a scheduler policy, which allows for custom actions
    like setting priority or removing/adding blocked/unblocked tasks
    to/from a runqueue.

* Combine `runqueue_*` crates with their respective  and `scheduler_*` crates,
  which is an improved design because external crates should not be able to
  view or modify a scheduler policy's internal runqueue contents.
  * This design makes sense, and also prevents issues like #1000.

* Modify most applications that access runqueues via the old `runqueue_*`
  crate APIs to go through the new `Scheduler` API instead.

----------
Signed-off-by: Klimenty Tsoutsman <klim@tsoutsman.com>
Co-authored-by: Kevin Boos <kevinaboos@gmail.com> 810e12f