Optimize File.dirname for common encodings

[byroot]

Closes: #15902

strrdirsep quite ineficiently search for the last separator from the front of the string.

This is surprising but necessary because in Shift-JS, 0x5c (backslash) can be the second byte of some multi-byte characters, (e.g. "ソ".encode(Encoding::SHIFT_JIS).b is "\x83\\"), as such it's not possible to do a pure ASCII search.
And it's even more costly because for each character we need to do expensive checks to handle this possibility, so the Inc macro end up being a major hotspot.

However in the overwhelming majority of cases, paths are encoded in UTF-8 or ASCII, so for these common encodings we can use the more logical and efficient algorithm.

This change also make strrdirsep suitable when n > 1, so it helps simplify the dirname_n function.

This PR also reduce the cost of dirname sanity checks of the provided path:

• str_null_check was performed twice, once by FilePathStringValue and a second time by StringValueCStr.
• StringValueCStr was checking for the terminator presence, but we don't care about that.
• FilePathStringValue calls rb_str_new_frozen to ensure fname isn't mutated, but that's costly for such a check. Instead we can do it in debug mode only.
• rb_enc_get is slow because it accepts arbitrary objects, even immediates, so it has to do numerous type checks. Add a much faster rb_str_enc_get when we know we're dealing with a string.
• rb_enc_copy is slow for the same reasons, since we already have the encoding, we can use rb_enc_str_new instead.

Many of these optimization could be applied to other path manipulation methods, but I'd rather do that in a followup.

compare-ruby: ruby 4.1.0dev (2026-01-17T14:40:03Z master 00a3b71eaf) +PRISM [arm64-darwin25]
built-ruby: ruby 4.1.0dev (2026-01-19T08:03:42Z file-dirname-opt-2 784d01ad99) +PRISM [arm64-darwin25]

	compare-ruby	built-ruby
long	4.027M	24.204M
	-	6.01x
short	15.548M	28.812M
	-	1.85x
n_4	3.845M	19.359M
	-	5.03x

[byroot]

urgh, damn windows. The crash doesn't give any info whatsoever. I might have to bisect the changes in some way :/

[launchable-app]

❌ 1/67299 Tests Failed

test/ruby/test_file.rb#test_stat 🛡️ never-failing, but failed now

Failure:
TestFile#test_stat [/tmp/_actions-runner-working-dir/ruby/ruby/src/test/ruby/test_file.rb:412]:
Expected |1768840877.9465432 - 1768840874.3029788| (3.643564462661743) to be <= 1.

[-> View Test suite health in main branch]

[nobu]

Will rb_enc_path_last_separator also be faster by scanning backward with rb_enc_prev_char?

[byroot]

Will rb_enc_path_last_separator also be faster by scanning backward with rb_enc_prev_char?

Oh, I didn't know that was a thing, I saw the algorithm I assume it was because scanning backward wasn't possible.

The PR is already pretty complex, and multibyte paths are rare, so I will merge like this, but I do plan to give the same treatment to other path methods.