BasicPolicy: allow the "wbr" tag for invisible word breaks

[jimklimov]

Tested in Firefox (editing the HTML preview area via F12 developer tools) that this tag is honoured to do word-breaks at HTML markup specified spots, and be a no-character when the rendered text is copied and pasted elsewhere.

Other types of injected word breaks we've tried involve invisible/zero-width Unicode characters which remain in copied rendered text and confuse programs they are pasted into (e.g. new Jenkins job arguments, Slack, NotePad++) despite often remaining invisible on display.

For context, our internal pipeline library generates "Badges" (via addShortText and friends) with job milestones, crucial arguments, etc. so test jobs scheduled by different team members are easily identifiable in the "left column" listing. Those texts are often copied around to re-run a similar test setup, communicate with team members, etc. Sometimes the individual tokens in those badges are too long as an unbreakable word (e.g. VAR=VALUE) and the badge width overflows the left column width. All browsers have a different opinion on what the word-separating characters in an otherwise unformatted text stream are, and how to interpret CSS hints about that, so the most functional option that worked for us was to explicitly inject the word-break hints into the markup.

But <wbr/> did not work with Safe HTML due to the policy enhanced here, and various HTML entities and Unicode characters (e.g. ​, ​, or ­ possibly hidden into invisible <div> so it is NOT SEEN when used as a word-breaking hyphen) are not all that copy-paste friendly.

• Solutions tried were inspired by the https://stackoverflow.com/questions/15841109/optional-line-breaking-html-entity-that-is-always-invisible discussion

• Experimental preview area (the "keywords" was originally spelled with <br> tag so it would end up in the generated markup, and that was edited to <wbr> to test the browser rendering ability):

• Reduced render area width does cause the mid-word wrap (with wbr actually injected there):

• F12 peek into the preview area:

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[jimklimov]

A simple web-edited fix to add one word ended up with a need to get to a computer and check out code and run mvn spotless:apply. Thanks for the easy life, automation :)