The link rel attribute should be handled as a token list to allow mixing manual link decorators for the same attribute

[niegowski]

Suggested merge commit message (convention)

Fix (engine): The link rel attribute will now allow mixing manual link decorators for the same attribute, as it will be now handled as a token list. Closes #13985, closes #6436.

Fix (mention): Mention should not be wrapped with an additional <span> when GHS is enabled. Closes #15329.

Internal (html-support): Attribute matching updated to the new output of Matcher#matchAll().

MINOR BREAKING CHANGE (engine): The ViewConsumable.consumablesFromElement() is removed and replaced with view.Element#_getConsumables() internal method. You should use ViewConsumable.createFrom() To create consumables if needed.

MINOR BREAKING CHANGE (engine): The ViewElementConsumables now accepts and outputs only normalized data. The ViewConsumable still accepts normalized or non-normalized input.

MINOR BREAKING CHANGE (engine): The Matcher#match() and Matcher#matchAll() output is now normalized. The MatchResult#match now contains normalized data compatible with changes in the ViewConsumable.

---

Additional information

For example – encountered issues, assumptions you had to make, other affected tickets, etc.

[Witoso]

@niegowski added closes #6436 as I think we mentioned it fixes this one as well.

[Witoso]

Before merging, let's discuss the release strategy, if it's coupled or not with linking experience.

[scofalik]

It's hard for me to approach this PR from top-level point of view and decide whether it is the best way to do it, but in overall, it makes sense and looks good. I rather focused on particular bits of code and possible logical/algorithmical/typo errors.

My two questions marks are:

1. I am not sure if it was a good decision to move some of the code to view elements. I mean generating consumables and merging elements. I don't know what was the reason to move it (e.g. if multiple parts of the code wanted to perform the same logic and view element was the best to keep it). If you decide that this is a must have, I'd recommend taking care to see if all related elements are moved. In one place I commented that it is weird that view element imports a type from conversion. I had such feeling a few times. Right now I am not convinced that moving code to view elements was a necessary change, but I don't have the holistic view on this PR/improvement, you spent more time on it.
2. Performance. Could you confirm that the performance does not drop, especially for samples where there is a lot of merging and unwrapping of view attribute elements (formattingLongPs, inlineStyles, wiki, ghs from the recently introduced performance tests).