Feature filters for translation prevention

[koskinenaa]

This pull request and the associated commits are motivated by a curious edge case when using Polylang with WP-Matomo Integration (WP-Piwik) plugin.

Here's the background briefly,

• A site was setup with Polylang and WP-Matomo Integration plugins
• The site used example.tld domain and 123 Matomo ID
• The site was migrated to foobar.tld domain and the Matomo ID changed to 321
• WP-CLI search-replace was used to change domain in the database, flush rewrites and transients, etc.
• Matomo ID was updated from the Dashboard via the plugin's settings page

Problem
After the site migration one could see the correct Matomo ID (321) in the admin view, but on the front-end the old ID (123) was used to generate the tracking script. Rather undesirable result.

Fix
It took me some time to realize that the Matomo ID option (wp-piwik-site_id) had found its way to the Polylang string translations, where the value was showing the new ID (321), but the translations still had the old ID (123). After clearing the string translations I got the tracking script working in the front-end with the correct Matomo ID (321) as Polylang was no longer interfering with the option value retrieval.

Investigation
After some digging I figured out that I could use the pll_get_strings filter to remove the Matomo ID option from the Polylang string translations list table and loop through the global $wp_filter to unhook any PLL_Translate_Option objects from the option_wp-piwik-site_id filter. This kind of filtering should prevent the same situation from arising again.

But to me this doesn't seem like an optimal solution as I'm basically erasing something that has already happened. In my opinion a better way would be to prevent the option string registration and the option value translation in the first place so that they don't ever happen.

Solution
The proposed filters would provide developers an easy way to prevent Polylang from registering or translating certain options or other strings.