kernel - Fix several usched nits

kernel - Fix several usched nits

* Fix an issue where a usched-restricted process is pulled onto a
  cpu that is outside of its mask.  The process will immediately
  push itself back onto a cpu in its mask, but this bug leads to
  unwanted cpu ping ponging.

* Fix an issue where cpu-bound usched-restricted processes can
  cause other processes to be misscheduled at a lower priority
  than their actual priority, resulting in unexpected stuttering.

* With these changes, nice +/- priorities should work considerably
  better.  In the normal case, alotted cpu time will be as shown
  below.  This is intended to be non-linear:

     1   RQ0N    1:42.11 forever
     2   R0N     1:22.55 forever
     3   R0N     0:51.46 forever
     4   RQ0N    0:24.23 forever
     5   R0N     0:23.12 forever
     6   RQ0N    0:19.91 forever
     7   RQ0N    0:09.08 forever
     8   RQ0N    0:08.38 forever
     9   RQ0N    0:06.46 forever
    10   RQ0N    0:06.72 forever
    11   RQ0N    0:04.65 forever
    12   RQ0N    0:04.60 forever
    13   RQ0N    0:03.04 forever
    14   RQ0N    0:02.53 forever
    15   RQ0N    0:02.16 forever
    16   RQ0N    0:01.55 forever
    17   RQ0N    0:01.25 forever
    18   RQ0N    0:00.81 forever
    19   RQ0N    0:00.76 forever
    20   RQ0N    0:00.32 forever

* In addition, dynamic priority operation should also work better with
  these changes.

* WARNING!  With this change, nice values actually work as intended.  A
  nice +20 process will get very little cpu in the face of a cpu-bound
  nice +0 process on a cpu.  Similarly, a cpu-bound nice -20 process will
  allow nice +0 processes to barely function on a cpu.

  And if you use an even larger spread, a cpu-bound nice -20 process
  will not allow a nice +1 or higher process any cpu time at all.

  Having multiple cores mitigations this somewhat, but users must be
  careful especially when specifying negative nice values for processes.

* If you run X and have jerkiness issues due to process load, you may want
  to give the X server itself around a nice -5.  You can fiddle, but in
  basic testing with everything running at nice 0, the scheduler appears
  to do a pretty good just generally.  For example, if your browser is
  so overloaded that it has essentially become cpu bound, it will get cpu
  on an equal basis with batch jobs like bulk builds.