[lwp] Fix a bug when lwp_pid_get_locked cannot find pid.Same thing with tid.

[yby-oy]

拉取/合并请求描述：(PR description)

[

为什么提交这份PR (why to submit this PR)

lwp_pid_get_locked中，当未找到pid时，返回的pid为current_pid + 1。

你的解决方案是什么 (what is your solution)

判断pid是否被找到l。

在什么测试环境下测试通过 (what is the test environment)

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification

[polarvid]

原先的实现从正确性上来说其实没有问题。这里混杂了两部分逻辑，静态资源分配，和 id 分配。静态资源分配是通过树结点模拟的链表加一个计数器实现的。id 分配就很暴力了，直接通过计数器遍历查找。

这个 PR 提到的问题其实就是被这两部分逻辑迷惑了。在算法的第一部分，完成静态资源分配以后，id 是一定可以分配成功的。而且，id 不一定是在静态资源的总数 (0, RT_LWP_MAX_NR] 范围内的。而是在 (0, PID_MAX] 范围之内。比如 RT_LWP_MAX_NR == 32，PID_MAX == 10000。10000 也是一个合法的 pid。只要静态资源池还有空闲的空间，分配就会成功。

但是从设计上看，其实整个算法应该抽象出一层，作为一个分配器在系统中复用。比如作为继承 resource id 类的拓展？另外，静态分配的方式对于 smart 其实也不是很合适。某些极端场景可能会在短时间内占用大量 pid，但是静态分配不能适应这种变化。