[SPARK-48686][SQL] Improve performance of ParserUtils.unescapeSQLString

[JoshRosen]

What changes were proposed in this pull request?

This PR implements multiple performance optimizations for ParserUtils.unescapeSQLString:

1. Don't use regex: following [SPARK-34263][SQL] Simplify the code for treating unicode/octal/escaped characters in string literals #31362, the existing code uses regexes for parsing escaped character patterns. However, in the worst case (the expected common case of "no escaping needed") it will perform four regex match attempts per input character, resulting in significant garbage creation because the matchers aren't reused.
2. Skip the StringBuilder allocation for raw strings and for strings that don't need any unescaping.
3. Minor: use Java StringBuilder instead of the Scala version: this removes a layer of indirection and may benefit JIT (we've seen positive results in some scenarios from this type of switch).

Why are the changes needed?

unescapeSQLString showed up as a CPU and allocation hotspot in certain testing scenarios. See this flamegraph for an illustration of the relative costs of repeated regex matching in the old code:

The new code is almost arbitrarily faster (e.g. can show ~arbitrary relative speedups, depending on the choice of input) for strings that don't require unescaping. For strings that do need escaping, I tested extreme cases where every character needs escaping: in these cases I see ~10-20x speedups (depending on the type of escaping). The new code should be faster in every scenario.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Correctness is covered by existing unit tests.

Was this patch authored or co-authored using generative AI tooling?

No.

[JoshRosen]

This needs another self-review to make sure that I haven't made any off-by-one errors and to assess whether we need to add more unit tests to better specify the existing unescapeSQLString behavior, but I'm opening it early to solicit feedback.

[LuciferYang]

Should we convert the String to a char[] within the method, so that we can use charArray(i) instead of String.charAt(i) to reduce the number of calls to String.isLatin1() to just once?

[JoshRosen]

Should we convert the String to a char[] within the method, so that we can use charArray(i) instead of String.charAt(i) to reduce the number of calls to String.isLatin1() to just once?

I considered this, but I don't think it's necessarily an obvious win: I think that the JIT should do a pretty good job of handling this character-by-character iteration pattern (it probably inlines the call and branch predicts it nicely). Given the overall size of the speedups from this PR so far, I'd prefer to just leave it as-is (I'd need higher resolution benchmarks to measure the charArray difference, I think).

[LuciferYang]

Should we convert the String to a char[] within the method, so that we can use charArray(i) instead of String.charAt(i) to reduce the number of calls to String.isLatin1() to just once?

I considered this, but I don't think it's necessarily an obvious win: I think that the JIT should do a pretty good job of handling this character-by-character iteration pattern (it probably inlines the call and branch predicts it nicely). Given the overall size of the speedups from this PR so far, I'd prefer to just leave it as-is (I'd need higher resolution benchmarks to measure the charArray difference, I think).

OK ~ Let's leave it as-is ~

[HyukjinKwon]

Merged to master.