Support internationalized WebFinger handles

[pfefferle]

I checked the plugin against the internationalized WebFinger handles notes from the SWICG. Receiving already worked, but non-ASCII handles were not recognized at all, and lookups did not use the form the notes ask for.

Proposed changes:

• ACTIVITYPUB_USERNAME_REGEXP matches letters and digits of any script now, plus + and %, and TLDs like xn--fiqs8s. It is used with the u modifier, so mentions and Webfinger::is_acct() accept handles like ελπίδα@ఉదాహరణ.example.
• Webfinger::get_identifier_and_host() builds the acct: URI the way RFC 7565 asks for: a non-ASCII userpart is percent-encoded and the host is the IDNA A-label. ASCII stays as it is, so anne.o'neill+notes is not encoded. The A-label also means wp_safe_remote_get() does not reject the lookup anymore.
• New to_ascii_host() converts a host with the IdnaEncoder that ships with core, so no intl extension is needed. fold_host() uses it, so all host comparisons treat the Unicode form and the A-label the same. A label that UTS Can't find my blog on Mastodon #46 maps to plain ASCII, like a soft hyphen or fullwidth Latin, is kept as it is, so it does not compare equal to a different host.
• Actors::get_id_by_resource() folds both sides, so acct: lookups work with the Unicode form, the A-label and any case.
• The WebFinger subject uses the A-label, via the new Webfinger::get_acct().
• The security agent knows about host folding, Unicode regexes and percent-decoding now, so a future audit checks this class of change.

Other information:

• Have you written new tests for your changes, if applicable?

Things that change for existing sites:

• In content with invalid UTF-8 only ASCII handles are linked, because the Unicode pattern needs valid UTF-8.
• acct: lookups are case-insensitive for the host now.
• On a site with a Unicode site URL the subject changes from acct:…@café.example to acct:…@xn--caf-dma.example. A server that compares cached subjects as plain strings would see a different value. I think that is fine, but I am not 100% sure.

Not covered: non-ASCII usernames (WordPress logins are ASCII only), actor IDs on a site with a Unicode site URL, and ' in a mentioned userpart, because wptexturize turns it into ’. Without the intl extension, hosts with decomposed accents, fullwidth letters or dots like 。 get a different A-label than with it.

Tests use data providers with the examples from the notes.

Testing instructions:

• Write a post that mentions an account with a non-ASCII handle, e.g. @ελπίδα@ఉదాహరణ.example: the mention is linked and the account is addressed.
• Search for a non-ASCII handle in the Reader or the follow form: it is found.
• On a site with an IDN domain, look up acct:user@xn--… and acct:user@… in Unicode form: both resolve, and the subject uses the A-label.

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

Support handles with non-Latin characters and domains with special characters, like @renée@café.example, in mentions, search and profile lookups.