Fix up minor problems in help topics

Please wait until #3041924: [META] Convert hook_help() module overview text to topics is otherwise fixed before making patches for this issue. It is currently Postponed.

We have made a few typos and there may be other minor problems with help topics to fix up... This issue is to collect them.

Here is the list of fixes to do:

1. benjifisher found this typo: in system.config_error.html.twig:
   

   enter the URL for your 403/403 pages, starting 
   

   Should say 403/404.

2. (Will be) FIXED in #3215784: [META] Fix up topics to use new help_route_link function alexpott found this in contact.setting_default.html.twig
   

   <p>{% trans %}Set a site-wide contact form to be the default contact form (the form that is shown on the <em>/contact</em> URL).{% endtrans %}</p>
   

   It's possible the /contact path is altered so might not be on /contact. I think we should link to the site wide contact form using the contact.site_page route.

3. On #3150364: Add a description for the language toolbar button to the CKEditor help page some text is being added to the CKEditor hook_help about the Language button that can be added to the toolbar. We need to make sure that information is also in our CKEditor topic or in an appropriate multilingual topic, or both, once that issue is finalized.
4. On #3150364: Add a description for the language toolbar button to the CKEditor help page they also made a list of accessibility features and a section about making accessible text. I'm not sure we covered that well in our topic on Accessibility, so we should check. See this screenshot of the output of one of the patches:
   
5. On #3067727: Convert comment, node, path, taxonomy module hook_help() to topic(s), the patch on #41 introduced the idea of adding a "Who can...?" section between Goal and Steps on Task topics, which tells what permissions you need to do the task. This seems like a good idea that maybe we should replicate on other Task topics?
6. On #3047711-43: Convert file, image, media, media_library, responsive_image module hook_help() to topic(s), catch brought up the question of terminology to use for "bundles" (entity sub-types). We had adopted (in the core.structure topic) the terminology of calling them "entity sub-types", as we did in the User Guide. On #1380720: Rename entity "bundle" to "subtype" in the UI text and help we decided that we should call things like Node, Taxonomy, etc., if we needed to talk about them as a group, "Entity types". Things like "Content type", "Vocabulary" we should call "Entity subtypes" if we need to talk about them as a group. Things like a node, a taxonomy term, etc. should be called "Entities". I believe we mostly have adopted this terminology in our help topics, but we should check and make sure -- we may have used the terminology "Entity item" instead of "Entity" for the individual items, and "sub-type" instead of "subtype".
7. Terminology for menu links should also be checked. They should be called menu links, not menu items or menu entries.
8. We have a number of links from topics in the Additional Information sections that go to drupal.org pages (either in the main docs or the User Guide). The link text is not consistent. Some of them have link text like "User Guide: Title of Topic" and others have link text like "User Guide topic on Title of Topic". We should standardize this. Easy to find -- grep for drupal.org in the topics.
9. core.maintenance.html.twig: "When performing maintenance, such as installing, uninstalling, or upgrading a module" ==> upgrading should be updating
10. block.overview.html.twig: "...module allows you to custom block types and custom blocks." --> needs the word "define' or "create" in there, like "allows you to define custom block types and create custom blocks"
11. shortcut.overview.html.twig: "Make sure that the core Shortcut module is enabled, " ... enabled => installed
12. #2144861: [meta] Replace Drupal in UI text with the name of the distribution reminds us we should not be using the word "drupal" in UI text (including help topics). So we should check over all the topics and make sure that is the case. I know it's being used in a few topics for links to the "Drupal User Guide" (see also next item
13. We have a lot of links to the User Guide, so part of this item is to make sure we're using a consistent link text for links to topics in the User Guide. The consistent format should not include the section number like "section 11.1" or "chapter 11", as this is subject to change as we add/rearrange topics in the User Guide.
14. core.config_overview.html.twig -- alexpott wrote on #3095734-102: Convert config module hook_help() to topic(s) (slightly edited for clarity): We need to add information about installing from configuration, as the part on cloning could encompass this. If people knew about and used installing from configuration more often then people wouldn't think so much about the site UUID.
15. On #2732113: Clarify in the dblog_help that the dblog module should not be used for forensic log they are adding a note to the dblog help about why the dblog module cannot be used as a "forensic" log. This should be added to a help topic too.
16. FIXED in #3192585: Fix up topics to use new help_topic_link function

    On #3090659: Make a way for help topics to generate links only if they work and are accessible we added a new help_topic_link function, which allows us to make links in topics without worrying about whether the module that "owns" the linked-to topic is enabled. In topics that we created before, we did things like this:

    If you have the core Actions module installed, see the related topic "Configuring actions" for more about actions.
    

    We should instead use the help_topic_link function to make a topic link, so it would look like this:

    {% set action_overview = render_var(help_topic_link('action.overview')) %}
    ...
    See {{ action_overview }} for more about actions.
    

    This is in quite a few topics... probably should search for the phrase "related topic" and that will find all/most of them.