i18n getMessage() placeholder bugs

We've noticed two bugs when using placeholders with i18n.getMessage():

1) When two placeholders surround a word without intervening spaces (i.e. "`$START_LINK_TAG$here$END_LINK_TAG`"), the substitution is incorrect (doesn't include the inner word and includes the placeholder title instead of the placeholder content). Spaces need to be added in between the placeholders and inner word for the substitution to be correct, but that workaround itself causes issues (see below).
2) If you pass an integer as a placeholder (i.e. `chrome.i18n.getMessage("example_message", [intValue])`, the placeholder is missing from the resulting message. This can be worked around by casting the numeric placeholder value to string first, but other browsers handle this case.

Neither of these issues occur in Chrome or Firefox.

**Steps to reproduce:**
Add the following code to these Safari Web Extension files (or use this demo extension https://github.com/lenacohen/Safari-Test-Extensions/tree/main/dnr-placeholder-bugs/i18n%20Placeholder%20Bugs)

__locales/en/messages.json_:
```
"popup_instructions_original": {
"message": "Integer placeholders don't appear instead of being cast as strings. Placeholders surrounding a word break unless there's at least one inner space: $COUNT$ potential $LINK_START$trackers$LINK_END$ blocked",
"description": "Popup message shown when at least one tracker was blocked.",
"placeholders": {
"count": {
"content": "$1",
"example": "15"
},
"link_start": {
"content": "$2",
"example": ""
},
"link_end": {
"content": ""
}
}
},
```

_popup.js_:
```
document.addEventListener('DOMContentLoaded', () => {
const msg = chrome.i18n.getMessage("popup_instructions_original", [
5,
"",
""
]);
document.getElementById('placeholder-test-original').innerHTML = msg;
});
```

_popup.html_:
`

**Expected Result:**
Popup contains the phrase "5 potential trackers blocked" ("trackers" is linked to https://privacybadger.org/#What-is-a-third-party-tracker)

**Actual result:**
The popup instead says: " potential LINK_END$ blocked"

**Workarounds:**
We've resorted to adding an extra space between the word and its surrounding placeholders (i.e. "`$LINK_START$ trackers $LINK_END$`”, "`$LINK_START$trackers $LINK_END$`”, or “`$LINK_START$ trackers$LINK_END$`”

The problem with this workaround is:
1) it is an issue in some locales (e.g. Chinese) where characters should be next to each other with no spaces and we don't want to introduce a weird space
2) the workaround is fragile, and in particular is difficult to manage with translators who will likely remove the space

**WebKit Bug**: https://bugs.webkit.org/show_bug.cgi?id=291956

Start with __locales/en/messages.json and the popup.js reproduction, using popup.html to observe the rendered result. Compare integer and adjacent-placeholder cases with the expected linked output, then review WebKit bug 291956; done when the reported cases produce the expected message without spacing workarounds.

Written by the indexing model from the issue text.