sched/sched: address performance concerns for sched_lock in non-SMP case

[pkarashchenko]

Summary

Address performance concerns from #7464

Impact

sched_lock/sched_unlock should work as fast as before.

Testing

Pass ostest from apache/nuttx-apps#1711

[pkarashchenko]

@davids5 Please take a look if this solution is better

[davids5]

@pkarashchenko
Are there more cases then:

1. The normal case sched lock prevents preemption from interrupts because we do not reprioritize while locked.
2. The case is that a call to change priority while locked must be accepted but delayed. But in fact this can only be the current task that is running and has locked.

Are there more?

[pkarashchenko]

@pkarashchenko Are there more cases then:

1. The normal case sched lock prevents preemption from interrupts because we do not reprioritize while locked.
2. The case is that a call to change priority while locked must be accepted but delayed. But in fact this can only be the current task that is running and has locked.

Are there more?

1. The shed_lock() does nothing when called from an interrupt
2. This is addressed by sched: fix context switching with locked scheduler #7464 and improved in this PR.