Improve ucaps.h _find_upper() and _find_lower() performance

[aaronp64]

Updated _find_upper() and _find_lower() to use a hashmap-like lookup instead of binary search. Reduces time of functions like String::findn(), String::to_upper(), and String::to_lower() by around 50-80% depending on strings used.

Compared using gdscript below:

extends Node2D

var text := "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

func _ready() -> void:
	test_findn()
	test_to_lower()
	test_to_upper()

func test_findn():
	var ms_start = Time.get_ticks_msec()
	var to_find := "abc"
	for i in 1000000:
		text.findn(to_find)
	var ms_end = Time.get_ticks_msec()
	print("findn: " + str(ms_end - ms_start) + "ms")

func test_to_lower():
	var ms_start = Time.get_ticks_msec()
	for i in 1000000:
		text.to_lower()
	var ms_end = Time.get_ticks_msec()
	print("to_lower: " + str(ms_end - ms_start) + "ms")

func test_to_upper():
	var ms_start = Time.get_ticks_msec()
	for i in 1000000:
		text.to_upper()
	var ms_end = Time.get_ticks_msec()
	print("to_upper: " + str(ms_end - ms_start) + "ms")

Old:

findn: 13111ms
to_lower: 6793ms
to_upper: 5231ms

New:

findn: 2428ms
to_lower: 1435ms
to_upper: 2241ms

[AThousandShips]

See also:

• [Core] Fix and optimize binary search #90036

[MewPurPur]

get_nearest_po2() * 2 for more speed? òwó

[aaronp64]

next_power_of_2() * 2 should work here, but would require changing next_power_of_2() to be constexpr. Size is only calculated once at compile time for each caps_table array, so speed shouldn't be an issue.

[Ivorforce]

Just to state it here too: I have opened #99971, which yields better performance benefits for latin texts.
That's not to say there's no value in this PR! #99971 only optimizes latin (ascii+) texts. Texts with non-latin contents, like chinese, would benefit from this PR. But we should be aware of this caveat when considering merging this :)