Change block entity form handler from 'off_canvas' to 'settings_tray'

Changing to new settings_tray.module component. @drpal thanks for script help! :)

Needs reroll at least for changes in #2803375: Rename Outside-in module to "Settings Tray" for real

@Jo Fitzgerald thanks the re-roll looks good!

So this patch is pretty simple so I think just a review to get it to RTBC.

Add change record for form and link template keys? https://www.drupal.org/node/2929216

+++ b/core/modules/settings_tray/settings_tray.module
@@ -86,8 +86,8 @@ function settings_tray_theme() {
-    ->setLinkTemplate('off_canvas-form', '/admin/structure/block/manage/{block}/off-canvas');

+++ b/core/modules/settings_tray/settings_tray.routing.yml
@@ -1,8 +1,8 @@
-    _entity_form: 'block.off_canvas'
-    _title_callback: '\Drupal\settings_tray\Block\BlockEntityOffCanvasForm::title'
+    _entity_form: 'block.settings_tray'
+    _title_callback: '\Drupal\settings_tray\Block\BlockEntitySettingTrayForm::title'

Since this route is to an @internal form do we need a change record for this?

DrupalCI Memory problem

Re #19 we could keep both the keys but I think we shouldn't because:

1. Its still an experimental module so code that integrates with it should be prepared to be updated
2. Keep both keys would be very confusing and I don't think would have any function. Settings Tray itself could only use 1 set to actually show the form in the off-canvas dialog. Would the only reason to leave is a module may have altered the form class for `off_canvas`.

   I think this is very unlikely but also if they altered it would most likely be with the intention of having Settings Tray use this form in the off-canvas dialog. So then we would get into situation of having to check if `off_canvas` key still after this change and if it was altered from `BlockEntityOffCanvasForm::class` then to use the new class instead. But then what if 1 module alters the deprecated `off_canvas` key and another modules alters the current `settings_tray` key? When would probably want to pick the current `settings_tray` key to respect but then what is the point of leaving `off_canvas` key as deprecated if we aren't going to respect it all the time.

My vote would be just rip the band-aid off and just switch to the new key.

The patch also need a re-roll

I was confused in #22 because I thought the proposal to was to also keep the form handler key.

Keeping the route key as deprecated seems like a good idea since the module already experimental beta.

The outbound route processor and the test coverage looks good.

Thanks @larowlan and @Wim Leers!

@rajeshwari10 thanks for the patch but it included unrelated changes.

When I am doing a reroll usually I check to make sure the patch file is about the same size the previous patch and then that it only modified the same files.
#31 is much bigger patch than #27

No changes just a reroll

@MerryHamster(BTW love username ;) ) thanks for the rerolled patch.

1. +++ b/core/modules/settings_tray/settings_tray.module
   @@ -19,12 +19,12 @@ function settings_tray_help($route_name, RouteMatchInterface $route_match) {
   -      $output .= '<p>' . t('The Settings Tray module allows users with the <a href=":administer_block_permission">Administer blocks</a> and <a href=":contextual_permission">Use contextual links</a> permissions to edit blocks without visiting a separate page. For more information, see the <a href=":handbook_url">online documentation for the Settings Tray module</a>.', [':handbook_url' => 'https://www.drupal.org/documentation/modules/settings_tray', ':administer_block_permission' => \Drupal::url('user.admin_permissions', [], ['fragment' => 'module-block']), ':contextual_permission' => \Drupal::url('user.admin_permissions', [], ['fragment' => 'module-contextual'])]) . '</p>';
   +      $output .= '<p>' . t('The Settings Tray module allows users with the <a href=":administer_block_permission">Administer blocks</a> and <a href=":contextual_permission">Use contextual links</a> permissions to edit blocks without visiting a separate page. For more information, see the <a href=":handbook_url">online documentation for the Settings Tray module</a>.', [':handbook_url' => 'https://www.drupal.org/documentation/modules/settings_tray', ':administer_block_permission' => Url::fromRoute('user.admin_permissions', [], ['fragment' => 'module-block']), ':contextual_permission' => Url::fromRoute('user.admin_permissions', [], ['fragment' => 'module-contextual'])]) . '</p>';
   ...
   -      $output .= '<p>' . t('To edit blocks in place, either click the <strong>Edit</strong> button in the toolbar and then click on the block, or choose "Quick edit" from the block\'s contextual link. (See the <a href=":contextual">Contextual Links module help</a> for more information about how to use contextual links.)', [':contextual' => \Drupal::url('help.page', ['name' => 'contextual'])]) . '</p>';
   +      $output .= '<p>' . t('To edit blocks in place, either click the <strong>Edit</strong> button in the toolbar and then click on the block, or choose "Quick edit" from the block\'s contextual link. (See the <a href=":contextual">Contextual Links module help</a> for more information about how to use contextual links.)', [':contextual' => Url::fromRoute('help.page', ['name' => 'contextual'])]) . '</p>';
   

   Thanks for catching this but we have to keep this issue scope limited.

   Take a look at https://www.drupal.org/core/scope#definition
   But generally

   Drupal core issues should include only a single scope, for example fixing a single bug with test coverage, or making one specific type of cleanup.

2. +++ b/core/modules/settings_tray/settings_tray.services.yml
   @@ -7,3 +7,12 @@ services:
   diff --git a/core/modules/settings_tray/src/Block/BlockEntityOffCanvasForm.php b/core/modules/settings_tray/src/Block/BlockEntityOffCanvasForm.php
   
   diff --git a/core/modules/settings_tray/src/Block/BlockEntityOffCanvasForm.php b/core/modules/settings_tray/src/Block/BlockEntityOffCanvasForm.php
   deleted file mode 100644
   
   +++ /dev/null
   @@ -1,194 +0,0 @@
   diff --git a/core/modules/settings_tray/src/Block/BlockEntitySettingTrayForm.php b/core/modules/settings_tray/src/Block/BlockEntitySettingTrayForm.php
   
   diff --git a/core/modules/settings_tray/src/Block/BlockEntitySettingTrayForm.php b/core/modules/settings_tray/src/Block/BlockEntitySettingTrayForm.php
   new file mode 100644
   

   We should be able to get git to recognize this as rename instead of delete and then new file.
   This will greatly reduce the size of the patch which will help reviewers because they won't to check to sure the new and old files are actually the same.

   To do this you can do something like
   git diff -M25% 8.6.x > ../mypatchfile.patch

3. +++ b/core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php
   --- /dev/null
   +++ b/core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php.orig
   

   This file is just left over from the `patch` command probably.

@Jo Fitzgerald looks good thanks