Wrong location of recipient handler UI

See comment in #3054695: Problem with recipient handler interface and spooling about the views-based recipient handler which I think wouldn't be possible with this and the related issue?

1. +++ b/config/optional/core.entity_form_display.node.simplenews_issue.default.yml
   @@ -33,7 +33,7 @@ content:
   -    type: options_select
   +    type: simplenews_issue
   

   Does this want an update hook? As you've removed the code from NodeTabForm, the module is effectively useless without the widget enabled.

2. +++ b/src/Form/NodeTabForm.php
   @@ -70,7 +59,6 @@ class NodeTabForm extends FormBase {
   @@ -124,44 +112,6 @@ class NodeTabForm extends FormBase {
   

   So we're keeping the NodeTabForm but moving the settings out of it.

   I think that it's right to put all the settings into the one widget, for the reasons you give on the IS.

   But having those settings live somewhere else other than the NodeTabForm where the sending happens is a bit of a weird UX.

   I suggest a follow-up issue to look at something like adding a 'simplenews' form mode for the node entity, enabling the issue field widget by default only on that form mode, and using that form mode on the NodeTabForm.

3. +++ b/src/Form/NodeTabForm.php
   @@ -215,29 +164,6 @@ class NodeTabForm extends FormBase {
   -      if (method_exists($class, 'settingsFormValidate')) {
   
   @@ -259,30 +185,6 @@ class NodeTabForm extends FormBase {
   -      if (method_exists($class, 'settingsFormSubmit')) {
   

   We don't seem to have preserved this ability for recipient handlers to validate or respond to submit.

   As I understand it the normal Drupal paradigm for plugins that provide forms is that they have build, validate and submit methods.

   So maybe we should add these to the RecipientHandlerInterface and empty implementations to the base class.

   Core has a PluginFormInterface, so maybe RecipientHandlerInterface should extend that.

4. +++ b/src/Plugin/Field/FieldWidget/IssueWidget.php
   @@ -0,0 +1,140 @@
   +    $button = $form_state->getTriggeringElement();
   +    $values = $button ? $form_state->getValue($button['#array_parents'][0]) : NULL;
   +    $handler = $this->spoolStorage->getRecipientHandler($items->getEntity(), $values);
   ...
   +      '#default_value' => $handler->getPluginId(),
   

   This is a pretty complicated approach to getting the handler id ... if there's a really good reason to do this rather than just loading the value stored in the field, maybe it's worth making a code comment explaining.

5. +++ b/src/Plugin/Field/FieldWidget/IssueWidget.php
   @@ -0,0 +1,140 @@
   +    $options = $this->recipientHandlerManager->getOptions();
   +    $element['handler'] = [
   

   If it worth hiding or disabling the handler if there is only one option?

6. +++ b/src/Plugin/Field/FieldWidget/IssueWidget.php
   @@ -0,0 +1,140 @@
   +      '#description' => t('Please select to configure who to send the email to.'),
   

   Hard to describe this. Some possibilities:
   "Select how recipients are identified."
   "How recipients should be selected."
   "Choose which procedure to use for selecting email recipients."

7. +++ b/src/Plugin/Field/FieldWidget/IssueWidget.php
   @@ -0,0 +1,140 @@
   +    if ($element['#value'] == '_none') {
   

   Wow, that's an arcane drupalism. Might be worth making a comment linking to #2448545: Modernize form select option helpers and/or #1585930: Render the _none option as an empty value for single select to allow client side validation for explanation.