Since 0c2d81dada, not all trace events are cleared during VM teardown.
This causes a crash when there is a tracepoint for
`RUBY_INTERNAL_EVENT_GC_EXIT` active during teardown.

The commit looks like a refactoring commit so I think this change was
unintentional.

[Bug #16682]

(cherry picked from commit b385f7670ffa420790bc548747fa4b58c4c5d8f6)

Block for `create_makefile` is expected to return the content of
the makefile.

BSD make can run parallel more aggressively than GNU make. It communicate
with other make process through -J option in MAKEFLAGS environment variable
to notify a build failure happend in an other pararell make process.
https://www.freebsd.org/cgi/man.cgi?make

It usually works well but ext/-test-/cxxanyargs/Makefile has two targets
which are expected to fail (failure.o and failurem1.o).

Additional note:
To test and debug this issue, following command will speed up it.
`make -f exts.mk -j8 clean all`

Asynchronous events such as signal trap, finalization timing,
thread switching and so on are managed by "interrupt_flag".
Ruby's threads check this flag periodically and if a thread
does not check this flag, above events doesn't happen.

This checking is CHECK_INTS() (related) macro and it is placed
at some places (laeve instruction and so on). However, at the end
of C methods, C blocks (IMEMO_IFUNC) etc there are no checking
and it can introduce uninterruptible thread.

To modify this situation, we decide to place CHECK_INTS() at
vm_pop_frame(). It increases interrupt checking points.
[Bug #16366]

This patch can introduce unexpected events...

I noticed that some files in rubygems were executable, and I could think
of no reason why they should be.

In general, I think ruby files should never have the executable bit set
unless they include a shebang, so I run the following command over the
whole repo:

```bash
find . -name '*.rb' -type f -executable -exec bash -c 'grep -L "^#!" $1 || chmod -x $1' _ {} \;
```