Improve performance and simplify usage of `block_has_support()` by supporting a string feature and avoiding `_wp_array_get()` for them

[flixos90]

Follow up to #58376: As mentioned in https://core.trac.wordpress.org/ticket/58376#comment:20, block_has_support() is one of the most notable functions that perform a ton of calls to _wp_array_get(). While that function can be useful, specifically for block_has_support() it is very much overkill, since almost every feature is just a simple string, i.e. uses a single-dimension array.

Additionally, passing an array for the $feature parameter is a bit confusing. Even the initial documentation accidentally defined a string, which suggests that was simply assumed to be correct as it is more intuitive (see #56307).

I am proposing the following:

• Add support for the $feature parameter of block_has_support() to be an array or string.
• If a string is provided, don't use _wp_array_get( $block_type->supports, $feature, $default_value ), but simply isset( $block_type->supports[ $feature ] ) ? $block_type->supports[ $feature ] : $default_value.
• Update all usages of block_has_support() that provide an array with just one item to just pass that item as a string.

Of course we could also count the items in the array and use isset() if it is just 1. But the approach of providing a string brings a similar performance improvement and is a more intuitive API.

[flixos90]

cc @aristath @spacedmonkey @soean

[nihar007]

Patch added

[nihar007]

One change in code

Trac ticket: https://core.trac.wordpress.org/ticket/58532

[mukesh27]

Thanks @thekt12 for the PR.

Left some feedback on the PR.

Moving to 6.4 milestone for consideration.

[swissspidy]

Of course we could also count the items in the array and use isset() if it is just 1. But the approach of providing a string brings a similar performance improvement and is a more intuitive API.

I'd suggest doing both, so that plugins and themes doing that will automatically benefit from such an enhancement too without having to do any code changes.

[flixos90]

After some quick performance benchmarks, there is no notable performance impact from this change, which is in line what I had seen earlier. This change is mostly about improving the API: Given most features to check for are simple strings, it is more intuitive to check for them like that, e.g. that way is in line with other feature check functions in WP core such as for post type support.

In terms of performance, the impact is negligible. It is safe to assume that the string check is marginally faster than using _wp_array_get(), but the change is certainly more about API clarity than about performance.

[mukesh27]

The function is introduced in 5.8, so set the version accordingly.

[flixos90]

In 56382:

Editor: Simplify usage of block_has_support() function by supporting a string.

Most block feature checks are for a single feature string, and for such cases it is not intuitive to require an array for the $feature parameter of the block_has_support() function.

This changeset brings it in line with other functions like post_type_supports(), allowing to pass a string for the $feature. An array is still supported for more complex cases where support for sub-features needs to be determined. This change furthermore includes a very minor performance tweak by avoiding calls to the _wp_array_get() function if a single feature string is being checked for.

Props thekt12, nihar007, mukesh27, swissspidy.
Fixes #58532.

Committed in https://core.trac.wordpress.org/changeset/56382