Patterns API: Use the requesting site's version to filter out incompatible patterns

[ryelle]

This uses the fact that WordPress sites send in the version number with each request to return only patterns that are supported by that version.

For example, the Link in Bio pattern would be flagged as 6.1, so that only sites with WP 6.1+ will see that result (except not yet, I haven't re-listed that pattern since until this is merged it will cause those console errors).

This is a fix for WordPress/gutenberg#45179, though it's not a long-term fix since the version needs to be manually set. Due to the setup of the pattern directory, running WP trunk + Gutenberg, we don't have an easy way to detect vanilla WordPress version issues. Patterns can be flagged manually (like I'll do for Link in Bio), if/when they're reported as broken. On the plus side, this doesn't require a core change :)

The version can be added via a sandbox: wp --url=wordpress.org/patterns post meta set [post id] wpop_wp_version 6.1

See #517

How to test the changes in this Pull Request:

Apply to a sandbox, and test with this URL — these three patterns have different version settings, so you can change wp-version in the URL and see the results change. "Shark Hero Banner" will only show on 6.0+, "Content Writer Block" on 5.9+, and "Simple Table" always.

https://wordpress.org/patterns/wp-json/wp/v2/wporg-pattern?locale=en_US&slug[]=content-writer-block&slug[]=simple-table&slug[]=shark-hero-banner&_fields=id,title,meta.wpop_wp_version&wp-version=6.2-alpha-54642-src

To test it locally, set up some patterns, and add the meta values using wp-cli.

1. Try listing patterns with /wp-json/wp/v2/wporg-pattern?_fields=id,title,meta.wpop_wp_version&wp-version=6.1.0
2. Change the version number, you should never see patterns with a higher version meta value than your setting.
3. If no version is passed in, all the patterns display