Add multilingual support for Canonical URL Notation Tool

[sybrew]

The new Canonical URL Notation Tool does not appear to support Polylang.

What we get: example.com/path-to-translated-page/ What we want: example.com/lang/path-to-translated-page/

Instead of transforming $wp_rewrite->front, it modifies the home_url() callback. WPML is in the same boat.

This is also why #675 is problematic.

We need to find a way to extract their "root."

I'd love to have this resolved before the final release, but I'm only halfway through the code review. And since this is only a visual issue (which I'm sure many will complain about), it's not a blocker.

[sybrew]

We may want to temporarily resort to the old behavior of displaying the canonical URL on translated pages by setting allowReferenceChange to false.

The value of defaultCanonical appears correct for both WPML and Polylang, which will then be locked in place.

[sybrew]

In f3b5de551884d1a5f3a780c57cf7bc4d469c564b, I added a check for allowCanonicalURLNotationTool (should have been allowCanonicalURLNotationTracker). It'll be set when TSF detects a translation plugin, and when set, the Canonical URL Notation Tool will be disabled.

In turn, users will see the URL WordPress predicts, which won't update until you save the post or term and may display a less useful GUID when creating the post.

This temporary hack short-circuits the result to the original placeholder. All other processing still takes place, which is inefficient and not up to my standards. Still, this change allows me to delay the fix to a later update, buying me time to find a proper solution.