On OpenBSD:

```
ld: warning: namespace.c:731(namespace.o:(rb_namespace_local_extension)): warning: strcpy() is almost always misused, please use strlcpy()
```

After upgrading GitHub to Ruby 3.4 we noticed that we stopped getting
useful C level backtrace information in our crash reports. We traced it
back to https://github.com/github/ruby/commit/7dd2afbe3a14d021e5554288517709f5778c3d58.

Passing 0 instead of -1 made sense for the Mach-O version of
`fill_lines`, but there is a separate ELF version of `fill_lines` that
still has special handling for -1: https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/addr2line.c#L2178-L2209

Without this special handling for the main executable, we don't have the
right `base_addr` when reading debug info, and so we fail to populate
the information for that line: https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/addr2line.c#L1948
Then we get to https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/addr2line.c#L2649,
and potentially (depending on how things were run) get back `"ruby"` as
`info.dli_fname` instead of the absolute path for the executable. We set
that as the `binary_filename` and then try to open it inside the next
call to `fill_lines`, but that fails (unless you happen to be in the
directory where the ruby executable lives) and break out of filling
lines entirely: https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/addr2line.c#L2673-L2674

This commit treats offset 0 as the main executable, rather than having
a special meaning for -1 (which gets turned into 0 anyway).

[Bug #21289]

On arm64 macOS, libunwind (both of system library and homebrew
llvm-18) seems not to handle our coroutine switching code.

.git-blame-ignore-revs will be updated after this commit is merged.

fill_lines is passed -1 for offset, which causes it to read the -1 index
of traces. This is not valid memory as -1 is reading before the trace
global variable in rb_print_backtrace. This code comes from commit
99d1f5f88b9b6de3124e31019902f91e030d334f, where there used to be special
handling for the -1 index.

We can see this error in ASAN:

    ==71037==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00010157abf8 at pc 0x00010116f3b8 bp 0x00016f92c3b0 sp 0x00016f92c3a8
    READ of size 8 at 0x00010157abf8 thread T0
        #0 0x10116f3b4 in debug_info_read addr2line.c:1945
        #1 0x10116cc90 in fill_lines addr2line.c:2497
        #2 0x101169dbc in rb_dump_backtrace_with_lines addr2line.c:2635
        #3 0x100e56788 in rb_print_backtrace vm_dump.c:825
        #4 0x100e56db4 in rb_vm_bugreport vm_dump.c:1155
        #5 0x100734dc4 in rb_bug_without_die error.c:1085
        #6 0x100734ae4 in rb_bug error.c:109

macOS clang 16 generates DWARF5, which have Mach-O section names that
are limited to 16 characters, which causes sections with long names to
be truncated and not match above.

See: https://wiki.dwarfstd.org/Best_Practices.md#Mach-2d-O

Suppress warnings/errors by -Wembedded-directive with `-std=c99` on
macOS.

Fix up commit 31d1226, "Avoid aborting inside addr2line.c".
Source code informations did not appear in C level backtrace since
that change.