Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>

Previously, it was decrementing the start argument until it reached
zero without actually changing the control frame pointer.

[Bug #14607]

Wait for the worker thread to finish.

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>

If `assert_equal(backtrace_locations.size, profile_frames.size)` in
`TestProfileFrames#test_matches_backtrace_locations_main_thread`
failed, we do not have enough information about it like that:

```
    1) Failure:
  TestProfileFrames#test_matches_backtrace_locations_main_thread [/home/runner/work/ruby/ruby/src/test/-ext-/debug/test_profile_frames.rb:148]:
  <31> expected but was
  <30>.
```

This patch shows both `backtrace_locations` and `profile_frames`
if failed.

[Feature #19755]

Before (in /tmp/test.rb):

```ruby
Object.class_eval("p __FILE__") # => "(eval)"
```

After:

```ruby
Object.class_eval("p __FILE__") # => "(eval at /tmp/test.rb:1)"
```

This makes it much easier to track down generated code in case
the author forgot to provide a filename argument.

The `rb_profile_frames` API did not skip the two dummy frames that
each thread has at its beginning. This was unlike `backtrace_each` and
`rb_ec_parcial_backtrace_object`, which do skip them.

This does not seem to be a problem for non-main thread frames,
because both `VM_FRAME_RUBYFRAME_P(cfp)` and
`rb_vm_frame_method_entry(cfp)` are NULL for them.

BUT, on the main thread `VM_FRAME_RUBYFRAME_P(cfp)` was true
and thus the dummy thread was still included in the output of
`rb_profile_frames`.

I've now made `rb_profile_frames` skip this extra frame (like
`backtrace_each` and friends), as well as add a test that asserts
the size and contents of `rb_profile_frames`.

Fixes [Bug #18907] (<https://bugs.ruby-lang.org/issues/18907>)

... in addition to normal iseq frames.
It is sometimes useful to point the bottleneck more precisely.

Right now `SomeClass.method` is properly named, but `SomeModule.method`
is displayed as `#<Module:0x000055eb5d95adc8>.method` which makes
profiling annoying.

This reverts commit r63265.

ko1 said I should not have committed this! I'm sorry!

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63267 b2dd03c8-39d4-4d8f-98ff-823fe69b080e