FileChooserWidget: Lengthen search activation delay to improve performance

Hi! This is me trying to provide a fix for issue #4133 (closed). It would make a huge difference in quality of life for me.

I tried grepping around the code but I couldn't make head or tails out of it (I really don't know how to deal with C anyway), and in the end I found out that there is one GtkBuilder ".ui" file related to the filechooser that mentions GtkSearchEntry, and this is where I have made the change. This is the most I am able to do by myself there, and I'm just crossing my fingers that this is the correct place for the fix.

Disclaimers:

• I have tested the effects of this change using the GTK4 filechooser dialog and the GTK Inspector, on both my slow and fast machines, to determine the optimal value for the delay. I could have put 750ms in there so that it could be even more lenient for slow typists and to reduce even further the risk of spamming search engines, but I figured that some eagle-eye users with very fast machines (recent CPUs and SSDs) might complain of a slightly noticeable delay for search to trigger; with 500ms, that delay is not noticeable.
• I hope this GtkBuilder file is the correct and only place needed to make this change, and that this will result in the GTK4 FileChooser Dialog "as used in most apps" to benefit from the changes; i.e. that it doesn't need to be hacked across the code elsewhere too.
• I have not been able to compile/test this change in practice/production, I have only "proven it to be correct" with the Gtk Inspector ;) I have no way to test on my real-world production system otherwise, as I know absolutely nothing about packaging and I fear I'd mess up my system (unless maybe someone provides some mock RPM package for Fedora 37 that I can download and test). But in theory, according to my testing (and positive results in other apps like GTG and Nautilus), this should cause no regressions.

Crossing my fingers! Thank you for considering this.