The template loader logic has grown a bit convoluted due to the recent addition of the concept of hybrid themes (i.e. both PHP and block templates allowed in one theme) and subsequent bug fixes (some of them related to child themes, others to custom page templates). #31498 had added unit test coverage to (hopefully!) cover exemplary cases from all those categories.

This allows us to more confidently simplify (and later, if needed, further extend) the template loader algorithm.

The core idea for simplifcation in this PR is as follows: 

`gutenberg_override_query_template( $template, $type, $templates)` is fed the results of Core's own template resolution algorithm. It provides a list of candidate `$templates` (e.g. `array( 'page-home.php', 'page-123.php', 'page.php' )`), and, if a matching template PHP file could be found in the current theme (including child and parent themes), that file's path in `$template` (e.g. `/var/www/html/wp-content/themes/test-theme/page-123.php`).

This means when attempting to find a block template, we iterate over `$templates`, but we cut off at the entry corresponding to our fallback PHP template (in the example case, we only pass `array( 'page-home.php', 'page-123.php' )` to `gutenberg_resolve_template` (the function that retrieves block templates)), since we're only interested to find block template counterparts for those candidate slugs (which have higher or equal specificity as our fallback PHP template), but not in any matches with lower specificity (e.g. `/var/www/html/wp-content/themes/test-theme/block-templates/page.html`).

The new logic is further explained in code comments.