FreeRTOS: add mutex hold count to task status info (IDFGH-3762)

[dexterbg]

This change enables applications to track down and debug stuck mutex priority inheritance and missing mutex release issues.

If uxCurrentPriority != uxBasePriority and uxMutexesHeld > 0, the task has taken a mutex which was then required by a higher priority task. That's normal FreeRTOS mutex priority inheritance, but should only occur temporarily. If uxMutexesHeld continues rising, the application has a bug in mutex management.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Alvin1Zhang]

Thanks for your contribution.

[uLipe]

@dexterbg , thanks for your contribution, Mutex debug utilities are always welcome :)

I just left a small minor comment, otherwise, LGTM.

[uLipe]

@dexterbg , could you please put this field around a configUSE_MUTEXES ifdef? Since this is more a debug feature, release applications may not use it, and it could be good to save more memory as possible on the TCBs.

[dexterbg]

@uLipe I would already have done so, if uxBasePriority was conditional. Why isn't it? Shall I include it in the ifdef?

[uLipe]

@dexterbg , the uxBasePriority were used to stuff related to the SMP and priority changing functions besides the mutex priority inheritance algorithm. So even if mutexes are not actually being used, these functions needs of this TCB field if I'm not missing something.

[dexterbg]

@uLipe Take a look at the TCB definition:
https://github.com/espressif/esp-idf/blob/master/components/freertos/tasks.c#L192

There is no uxBasePriority even in the TCB without configUSE_MUTEXES. My assumption would be, this condition has been forgotten on the initial inclusion of uxBasePriority into struct xTASK_STATUS.

[uLipe]

@dexterbg , I was also afraid this was left behind to its usage by espcoredump component (which currently has very strict rules about data structure size and depends on freertos tasks).

After looking better, the implementation, leaving both fields without #ifdef will keep the freertos code close of the upstream version, so please just ignore my suggestion.

Thanks again for your contribution