Support Twig, TO, CC, BCC, FROM, REPLY-TO, SUBJECT, Message, Abort, Debugging and Tips

This is a major enhancement of the Content Moderation Notifications (CMN) module allowing complete control of TO, CC, BCC, FROM, REPLY-TO, SUBJECT, and MESSAGE fields, adding full Twig support to all fields, changing Token support, allowing dynamic messages to be displayed, improved support for hook_mail_alter(), intelligent non-sending of notifications if no recipients or if a specified "Abort" email is found, expanded help text on fields, a VERY helpful debugging mode (no more switching back and forth between email and web a zillion times) and on-screen list of commonly used {{ variables }}.

1. Add Twig support
   1. Working patch in #2953489: Add Twig support in Subject, Email, and Message fields → , which is being dropped in favor of this expanded module.
   2. All text fields are now draggable-expandable textarea fields
   3. Helpful UI feature auto-expands all fields (on page load) to show full contents of all fields without having to manually resize them
3. Replace "Recipients" (in #2946360: Make the recipient configurable → ) and "Adhoc Email addresses" fields with more standard TO, CC, BCC, FROM and REPLY-TO
   fields. (high priority)
   1. This would allow people to form the emails however they want, particularly if we include the Twig templating
      logic on all of them.
4. Prevent sending emails if no recipients
   1. No email will be sent if there are no recipients specified in the TO, CC and BCC fields.
5. Allow an Abort ("kill-switch") email address (maybe "abort@example.com" or "noemail@example.com") that, if found in any
   address or message field, will cause the module to NOT send a notification message. (Medium Priority)
   1. This would be useful in use cases such as "if the editor is also the author, don't send them an email (since
      they already know it's reviewable or published)", and the twig logic could return the abort@example.com email in
      this case to prevent emails from being sent.
   2. The current module would still send the email to the Recipient (site email address) even if no other
      recipients are specified.
6. Allow Dynamic messages to be displayed on-screen after notifications are sent by using Twig Tweak module's drupal_set_message() function. For example, in any field you can add the Twig code:
   1. {{ drupal_set_message( ':author has been notified of this edit'|t({':author' : user.displayName})) }}
7. Add a "Debug Mode" checkbox that would display all the fields (To, Cc, Bcc, From, Message, etc.) to the screen via
   drupal_set_message() and NOT send out any emails.
   1. This will make debugging messages and Twig code much simpler and much less spammy.
   2. Debugging can be done without switching between Drupal and email apps.
8. Pass mail key containing Notification.id instead of module name
   1. This would allow hook_mail_alter() calls to be able to target specific notifications
9. Add an expandable "Common Replacement Patterns" section to the Edit Notification page
   1. Include a list of the most common tags, such as {{title}}, used in the messages
10. Figure out a decent way of having non-WYSIWYG Twig code in the Message value (Lower Priority)
    1. Putting Twig code in the WYSIWYG can be challenging as it adds DIV, SPAN and NBSP in the code
    2. Working in Source view defeats the point of having the WYSIWYG
    3. Simple solution would be to include an external template. Examples:
       1. {% include('cmn--editorial--draft.twig.html') %}{# have the template do all logic and output #}
       2. {% include('cmn--editorial--draft.twig.html') %}{# have the template do only logic and put output after here #}{{ user.email }} Edited this Draft
    4. Any better ideas on how to do this?
11. Figure out a better way of handling Twig errors than WSOD and having to look at the logs for the error
    message
    1. Maybe wrap in try..catch and display an error (at least if in Debugging mode)

These updates aren't perfect yet but I wanted to get it up ASAP to gather any feedback before final polishing. Any help (particularly with writing tests) is welcome!

The existing patch is fully functional and is in production use now.

Things Still To Do (that I know of):

4. Update README.txt
   1. Update for the new features
   2. Provide examples
5. Clean up code
   1. Remove commented debugging/obsolete code
   2. Conform to Coding Standards