FIX Tag check and tag handling for LanguageResource matches

When TM matches are accepted in the TM panel / concordance serach, additional whitespace tags in the match are automatically stripped, when the segment is saved.

The reason for this is a quirky architecture of the HtmlEditor.js class:
    
the prop "markupImages" is used as a cache for converting the internal-tags to image-tags for the editor (markup and unmarkup API, HtmlEditor::insertMarkup and HtmlEditor::setMarkupImages) and at the same time to validate the tags in the tag-check against when saving. This is preventing a proper seperation of concerns and a better solution is needed:

• The reference to compare in the tag check is generally the segment  source (for translation tasks) or the target at import-time for review tasks (->  RowEditorColumnPart::loadRecord). Review tasks are those, where at least a number of segments have a filled target in the imported xliff. See corresponding LEK_task flag.
• If not already present, isPretranslated, isTranslation and isReview shorthands shall be added to the task entity (frontend and backend)
• The tag-cache "markupImages" shall be used for conversion/creation of tags only.
• The tag-check shall work on the serialazied reference to compare, not the tag-cache, it also does only check whitespace-tags or special character tags, when the config property untimeOptions.segments.userCanModifyWhitespaceTags is set to false.
• when accepting TM-matches, the inserted markup should have the internal tags ("<1>, <2> ...) replaced with the ones from the tag-check-reference, internal tags not present in the reference shall be stripped, only whitespace and  special characters can be added by accepting the match (and thus have to be added to the "markupImages" cache - what should be achieved automatically with "insertMarkup") 

Generally, the Tag-Check shall become an own class and independent from the tag-conversion and the "markupImages" cache must always represent the current state of the shown markup in the editor

The new class should be written in a way, that it can still be used with the existing old segment editor, but also with the upcoming new one.