Fix: UI: Fuzzy Search: incorrect max acceptable edit distance for deletions in short words

This fixes an edge case in how the max acceptable edit distance is calculated
for deletions in fuzzy search, wherein the padding added to the max error count
could be negative when the query was longer than the matched term, producing a
max distance of zero.

This came up in chat a while back, where someone noted that, in the compositor,
searching for "bluir" wouldn't return the blur nodes; "blu" worked, "blui"
worked,  but "bluir" returned no results, despite all three having equal edit
distances (1 insertion, 1 substitution, and 1 deletion, respectively). The edit
distance metrics themselves are calculated correctly; the issue was just with
how the distance threshold was set.

Pull Request: https://projects.blender.org/blender/blender/pulls/143741

source/blender/blenlib/intern/string_search.cc

@@ -125,7 +125,7 @@ int get_fuzzy_match_errors(StringRef query, StringRef full)
   const char *window_begin = full_begin;
   const char *window_end = window_begin;
   const int window_size = std::min(query_size + max_errors, full_size);
-  const int extra_chars = window_size - query_size;
+  const int extra_chars = std::max(window_size - query_size, 0);
   const int max_acceptable_distance = max_errors + extra_chars;
 
   for (int i = 0; i < window_size; i++) {

source/blender/blenlib/tests/BLI_string_search_test.cc

@@ -36,6 +36,7 @@ TEST(string_search, get_fuzzy_match_errors)
   EXPECT_EQ(get_fuzzy_match_errors("hello", "hallo"), 1);
   EXPECT_EQ(get_fuzzy_match_errors("hap", "hello"), -1);
   EXPECT_EQ(get_fuzzy_match_errors("armature", UI_MENU_ARROW_SEP "restore"), -1);
+  EXPECT_EQ(get_fuzzy_match_errors("bluir", "blur"), get_fuzzy_match_errors("blur", "bluir"));
 }
 
 TEST(string_search, extract_normalized_words)