What this PR does / why we need it: in developing and testing the HEAL metadata block, and reviewing use of ORCID/ROR in various configurations of parent/child fields, several errors and limitations in the edit/display UIs have been discovered (or re-discovered). The issues are not specific to this block and could be helpful in other blocks as well. (Note that some fixes require changes to the displayformat of fields in the block as well.)

This PR addresses these issues:
- Support for the display of multiple child field values
- The ability to format child fields to display the name once followed by the multiple values
- Allows the name of a child field (of any type - text, string, int,float, email, etc.) to be bolded when displayed
- Separation of multiple textbox field values onto separate lines (affects primitive fields like the citation Related Materials field)
- Allows display of child fields (of any type) on separate lines
- Supports internationalization of child controlled vocab fields
- Avoids duplicate display of a child field where the parent and/or other child fields use external vocabulary fields but the child is not a term-uri or managed field
- Avoids long CVV entries in child fields from overlapping with other child fields by allowing them to wrap - in the edit pane for selected values. (Pop-up dialogs for selection are still allowed to cover adjacent child fields.)
- Allows display of emails in child fields, with @ replaced by [at] and . replaced by [dot]

Which issue(s) this PR closes:

Related to #368

• Closes #12529 (already closed)

Special notes for your reviewer:

• Previously, url fields were allowed to use the <a> field. This PR allows use of <b> and <br/> tags as well and allows this on other types of fields. (The value for these fields still have tags stripped.) However, for all of these, if one of these tags is used in the displayformat in the metadata block, other tags can also be used - a security risk, but one limited to users who can create/install blocks. Without knowing if someone has used this loophole for url fields already, I didn't want to tighten security in this PR but, if someone wants to specify a list of allowed html markup for displayformat, I can add jsoup deletion of any other tags to close this hole.


• The code now separates the concepts of isEscapeOutputText - which is decided based on whether user input is escaped (we currently allow some html in the url and textbox field types, and don't allow html in other types) - and isEscapeFieldText() - which is decided based on whether the displayformat includes html that shouldn't be escaped. When isEscapeOutputText is true and isEscapeFieldText is false, the user inputs are stripped of html but the field in UI is displayed as html so the display formatting works.


• The existing code hides any email field with the format #EMAIL- replacing #EMAIL in the format with a blank string. (It does not hide the email if the displayformat was null or #VALUE.) Hiding makes sense for the datasetContactEmail field, where we have text to say use the contact form instead, but it seems odd to always treat #EMAIL as a way to hide a field. This PR makes a slight change - it keeps #EMAIL as a way to blank the field, but allows for formats such as #NAME: #EMAIL (or that with some html formatting) to show the email, but does a minimal conversion to the string, e.g.: support:[at]dataverse[dot]org. I'm not set on the particular form, but it seems like some option between blank and raw email string might be useful - happy to adapt to suggestions.

Suggestions on how to test this: Some changes can be tested on the citation block, some with the CVoc scripts as deployed on demo, but the bulk of them are probably easiest to test using the HEAL metadata block (the old version and old code vs an updated block with new displayformat entries (see #3) and this PR).

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
This is what the HEAL metadata looks like with displayformat=<b>#NAME:</b> #VALUE<br/> :

For the edit display, this shows wrapping of long values:

Is there a release notes update needed for this change?:
tbd
Additional documentation: