Prioritise results by requested locale, but return Locale and default (en_US) patterns.

[dd32]

Currently the Pattern directory limits the results to the given locale, this is not ideal in all situations.

Consider:

• https://ru.wordpress.org/patterns/ currently has no patterns, as none are translated
• https://cs.wordpress.org/patterns/ currently only has a single partially translated pattern.
• Results inside Gutenberg reflect the above.
• https://api.wordpress.org/patterns/1.0/?locale=foo_bar returns no results. The foo_bar locale is admittedly not used on any sites, but it's not uncommon to see API requests with it set to en or es which are equally invalid WP_Locale values.

This PR changes the logic from only returning results in the matching locale, to returning in both the local and in en_US, with the localised results first.

No attempt at deduplication is done here, both the Translated and english results would be returned.
This also has the benefit that searching an English phrase would result in matching an english pattern, and not just returning an empty data set if it's not included in the locale translated patterns. Searching for a German phrase on an English or French site would however not return a matching German pattern.

See #244

Screenshots

How to test the changes in this Pull Request:

1. Apply patch
2. Visit URLs mentioned. Perform searches.

[dd32]

I also note that this introduces a query alteration which will require writing some manual ElasticSearch rules when time to implement that comes along.

[iandunn]

it's not uncommon to see API requests with it set to en or es which are equally invalid WP_Locale values

Some recent WPCOM discussion around that is at D64053-code

[iandunn]

No attempt at deduplication is done here, both the Translated and english results would be returned.

That's not ideal for en_* locales, since e.g., the en_AU and en_US versions of About me cards will both appear.

https://en-au.wordpress.org/patterns/search/about/

We can probably de-dupe via post_parent, but that can be an iteration in another PR. I'll open an issue.

[iandunn]

LGTM. I'll go ahead and merge/deploy since it's early in Australia and this'll improve results for folks upgrading to 5.8.