LU-17242 debug: use dump_stack() where possible

LU-17242 debug: use dump_stack() where possible

In some cases, libcfs_debug_dumpstack() can fail to output a
stack trace - either because the needed symbols are not exported
or those symbols can't be resolved at runtime. This seems to
occur more often with newer kernels. The messages appears only
as:

 Lustre: ldlm_cb01_002: service thread pid 57876 was inactive for
   40.494 seconds. The thread might be hung, or it might only be
   slow and will resume later. Dumping the stack trace for
   debugging purposes:
 Pid: 57876, comm: ldlm_cb01_002 6.1.70 #1 SMP PREEMPT_DYNAMIC
   Thu Jan  4 18:52:41 UTC 2024
 Call Trace TBD:

with no stack trace (seen on CentOS 8.5 with ml 6.1.70).

For reference, the runtime symbol lookup was added and updated in:

 b49ce7a ("LU-12400 libcfs: save_stack_trace_tsk if ARCH_STACKWALK")
 58ac9d3 ("LU-14099 build: Fix for unconfigured arch_stackwalk")

First, add a message when the symbol can't be resolved correctly.
This makes it much easier to understand why the stack trace is
missing.

Second, replace libcfs_debug_dumpstack(NULL) with dump_stack().
When the task_struct is NULL, libcfs uses the current
task_struct. This replicates the functionality of dump_stack().
Using dump_stack() is more reliable, more in line with kernel
style, and not likely to be un-exported in the future.

Finally, in lustre/osc/osc_object.c the stack isn't dumped since
there is already an LBUG().

There only remains one user of libcfs_debug_dumpstack() which
uses a task_struct other than current. This can be cleaned up
in a future patch.

Test-Parameters: trivial
Signed-off-by: Timothy Day <timday@amazon.com>
Change-Id: I196c1da7e39b1a694c0cb67ecfaab58ab3e4662c
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/53625
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Reviewed-by: Patrick Farrell <pfarrell@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>