sched: add nxsched_remove_self

[hujun260]

Summary

In the scenario of active waiting, context switching is inevitable, and we can eliminate redundant judgments.

code size
before
size nuttx
text data bss dec hex filename
262848 49985 63893 376726 5bf96 nuttx

after
size nuttx
text data bss dec hex filename
263324 49985 63893 377202 5c172 nuttx

reduce code size by -476

Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic
-machine virt,virtualization=on,gic-version=3
-net none -chardev stdio,id=con,mux=on -serial chardev:con
-mon chardev=con,mode=readline -kernel ./nuttx

Impact

Testing

[hujun260]

The previous function nxsched_remove_readytorun suffered from being overly complex in its logic judgments due to its comprehensive functionality,
which also made it inconsistent with its name. By splitting this function into multiple, more specific functions for different scenarios,
we can significantly reduce the complexity of the code.

For instance, the intricate implementation of the TLIST_HEAD macro was once a necessity to be invoked frequently,
but now it's only required in certain scenarios, leading to a decrease in its frequency of use.
There are similar implementations that have undergone similar optimizations.

After these optimizations, we tested nxsem_wait and observed an approximate 10% performance gain in terms of cycles.

[anchao]

1. nxsched_add_readytorun()/nxsched_remove_readytorun() are paired functions. If you feel the logic is not clear enough, you could separate the requirements according to the task status and merge list, but do not expose it to kernel developers, which will reduce the readability of the code and increase the maintenance cost.
2. About newly added interface in this PR, there are special requirements for thread status and list merging, but in nxsched_remove_readytorun(), there will only be a few more conditional branches(if). If you want to optimize, we could add parameters to nxsched_remove_readytorun instead of using inexplicable interfaces to confuse developers.
3. nxsched_remove()? did not you think the function naming is weird?

Kernel interfaces are as reusable as possible. We need to balance some performance (if), which does improve code readability and avoids many rookie errors. I don't want to see all interfaces in the future like freertos (****_FromISR)

[hujun260]

1. nxsched_add_readytorun()/nxsched_remove_readytorun() are paired functions. If you feel the logic is not clear enough, you could separate the requirements according to the task status and merge list, but do not expose it to kernel developers, which will reduce the readability of the code and increase the maintenance cost.
2. About newly added interface in this PR, there are special requirements for thread status and list merging, but in nxsched_remove_readytorun(), there will only be a few more conditional branches(if). If you want to optimize, we could add parameters to nxsched_remove_readytorun instead of using inexplicable interfaces to confuse developers.
3. nxsched_remove()? did not you think the function naming is weird?

Kernel interfaces are as reusable as possible. We need to balance some performance (if), which does improve code readability and avoids many rookie errors. I don't want to see all interfaces in the future like freertos (****_FromISR)

i update patch just add one interface nxsched_remove_self