translation#67 - Allow translation of fields which lack an explicit HTML type

_Overview_: The `Translation` entity can be used to translate certain fields. Currently, the field settings (`data_type`, `html_type`)
must satisfy some requirements before being translated. This change slightly relaxes those requirements.

_Before_: String fields can be flagged as translatable - but only if they a text-style HTML widget.

_After_: String fields can be flagged as translatable - if they have text-style HTML widget or no clear widget.

_Comments_: This is motivated to allow `civicrm_msg_template` (`msg_subject`, `msg_text`, `msg_html`) to marked as translatable.

The `data_type` and `html_type` constraints were introduced during a much earlier draft. At that time, the list of fields was
open-ended. Now, the list is much narrower (default=none) and requires an extra opt-in (`hook_translateFields`). Consequenty,
there's less concern about someone trying to translate an inappropriate field.

This patch seemed simplest/lowest-change, though I am open/ambivalent about any of these approaches:

* Completely remove the HTML-type constraint.
* Change the `html_type` data for `MessageTemplate`. (But I don't know if this will have other side-effects.)

CRM/Core/BAO/Translation.php

@@ -114,7 +114,7 @@ class CRM_Core_BAO_Translation extends CRM_Core_DAO_Translation implements \Civi
   public static function self_civi_api4_validate(\Civi\Api4\Event\ValidateValuesEvent $e) {
     $statuses = self::getStatuses('validate');
     $dataTypes = [CRM_Utils_Type::T_STRING, CRM_Utils_Type::T_TEXT, CRM_Utils_Type::T_LONGTEXT];
-    $htmlTypes = ['Text', 'TextArea', 'RichTextEditor'];
+    $htmlTypes = ['Text', 'TextArea', 'RichTextEditor', ''];
 
     foreach ($e->records as $r => $record) {
       if (array_key_exists('status_id', $record) && !isset($statuses[$record['status_id']])) {