[POC] Implementing some components of the Ajax system using HTMX

Problem/Motivation

This task is a proof-of-concept for #3404409: [Plan] Gradually replace Drupal's AJAX system with HTMX as requested by @nod_.

Reference Links

• Ajax API
• HTMX reference documentation
• HTMX contrib module

Remaining tasks

1. One or two examples (at least) of replacements for existing core ajax
2. A list of the various ajax commands we have in core and their feasibility
   (with a very rough complexity estimate easy/hard) with htmx
   • #wrapper (content replacement) does this use InsertCommand or one of it's descendants for implementation?
   • AddCssCommand
   • AddJsCommand
   • AfterCommand
   • AlertCommand
   • AnnounceCommand
   • AppendCommand
   • BeforeCommand
   • ChangedCommand
   • CloseDialogCommand
   • CloseModalDialogCommand
   • CssCommand
   • DataCommand
   • FocusFirstCommand
   • HtmlCommand
   • InsertCommand
   • InvokeCommand
   • MessageCommand
   • OpenDialogCommand
   • OpenModalDialogCommand
   • OpenOffCanvasDialogCommand
   • PrependCommand
   • RedirectCommand
   • RemoveCommand
   • ReplaceCommand
   • RestripeCommand
   • SetDialogOptionCommand
   • SetDialogTitleCommand
   • SettingsCommand
   • TabledragWarningCommand
   • UpdateBuildIdCommand
   • UpdateSelectionCommand
3. Test runs don't need to be green, although it' be nice if a couple of them
   were passing.
4. can we use this to handle ajax form submit? if yes, how complex does it
   look? would be great to drop our jquery formsubmit fork
5. A big thing here is to improve DX, so a couple of examples of how it could
   make it easier to introduce some ajax stuff in contrib/projects would be
   good.
6. rough dependency evaluation
   (See Criteria for adding dependencies)
7. BC strategy (support existing calls, or a new codepath altogether, etc.)
   I'm not too keen on two separate mods. I feel it'll make adoption much, much
   slower than spending time on the BC layer even if it takes a long time. (we
   can always put restrictions on what the BC layer can do) if we have 2 code
   paths, we'd need a contrib module to bridge the two and let contrib
   maintainers test with htmx easily without changing their code

User interface changes

API changes

Data model changes

Release notes snippet