When using M:N threads, EC is set to NULL in the shared native thread
when nothing is scheduled. This previously caused a segfault when we try
to examine the EC.

Returning 0 instead means we may miss profiling information, but a
profiler relying on this isn't thread aware anyways, and observing that
"nothing" is running is probably correct.

Fixes [Bug #20017]

Co-authored-by: Dustin Brown <dbrown9@gmail.com>

If we always return 0, we might as well not define
the function at all.

Co-authored-by: Jean Boussier <byroot@ruby-lang.org>

rb_backtrace_t is 32B, so it fits well in a 80B slot.

There is some unused spaces but given Backtrace objects are
rarely held onto it should be inconsequential and avoid
the malloc churn.

Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>

The struct is 16B, so they will use the 80B size pool, so on paper it
wastes 80 - 32 - 16 = 52B, however most malloc implementations will
either pad sizes or use an extra 16B for each segment, so in practice
the waste isn't that big. Also `Backtrace::Location` are rarely held
on for long, so avoiding the malloc churn help performance.

Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>

Add a new API rb_profile_thread_frames(), which is essentialy a
per-thread version of rb_profile_frames().

While the original rb_profile_frames() always returns results about the
current active thread obtained by GET_EC(), this new API takes a Thread
to be profiled as an argument.

This should come in handy when profiling I/O-bound programs such as
webapps, since this new API allows us to learn about Threads performing
I/O (which do not have the GVL).

Profiling worker threads (such as Sidekiq workers) may be another
application.

Implements [Feature #10602]

Co-authored-by: Mike Perham <mike@perham.net>

Frames pushed by YJIT have an unreliable PC.  The PC could be garbage,
and if we try to read the line number with a garbage PC, then the
program can crash.

This commit returns line 0 for programs where there is a `jit_return`
function.  If `jit_return` has been set then this frame was pushed by
the JIT, and we cannot trust the PC.

Here is a debugger session for a program that crashed due to a broken
PC:

```
(lldb) p ruby_current_vm_ptr->ractor.main_thread->ec->cfp->iseq->body->iseq_encoded
(VALUE *) $0 = 0x0000000118a30e00
(lldb) p/x ruby_current_vm_ptr->ractor.main_thread->ec->cfp->pc
(const VALUE *) $1 = 0x0000600000b02d00
(lldb) p/x ruby_current_vm_ptr->ractor.main_thread->ec->cfp->jit_return
(void *) $2 = 0x000000010622942c
```

You can see the PC is completely out of range, but there is a
`jit_return` pointer so we can avoid this crash.

According to the C99 specification section 7.20.3.2 paragraph 2:

> If ptr is a null pointer, no action occurs.

So we do not need to check that the pointer is a null pointer.