Update topic contact.setting_default to use route instead of "/contact"

Updated remaining tasks to include instructions for testing.

Updated issue summary's remaining tasks for clarity.

Looking at MR, it's doing what I suggested in the issue summary (thank you!) but I'm not crazy about the resulting grammar, now that I look at it. Going to ask for a 2nd opinion on that before we finalize this.

Thank you all for the quick MR and review.

Oh, wait a minute, I made a mistake and confused the routes. Sorry about that! The route we already have is the route to the admin page that lists all contact forms entity.contact_form.collection. We don't have vars for the route to the default contact page (contact.site_page).

Also, although I couldn't find where /contact is configurable (or maybe it's just alterable in a custom module?), apparently it is, which is why this issue exists. So we shouldn't use the literal text "/contact" or its default route title, "Contact". The title of the page will vary, depending on which contact page is configured to be the default contact page (that's what this help topic describes in fact).

Ok. So there are 2 things to note/to do:

1. The route to /contact (e.g. the default contact form page) is contact.site_page. We don't have Twig variables set up for that route yet. (Use the existing pair of Twig variables in this topic as a guide. Both the route and the link text will need to be updated.)
2. The Goal (the sentence we are updating with this link) need to be rephrased so that the link to the contact.site_page route can be added. It needs to be rephrased in a multilingual-context-friendly way. Since we won't know the title, this is tricky! Perhaps if we link the entire parenthetical phrase, that will work, because the entire context can be translated. The rendered HTML could be something like:

<p>Set a site-wide contact form to be the default contact form (<a href="/contact">the form that is shown at the default contact page; for example, <em>/contact</em>)</a>).</p>

That shows that the URL might be /contact, but describes the page, just in case it isn't. And the whole phrase is linked, allowing for hopefully enough context for translators to make sense of it.

If we adopt that suggestion, here are the changes that need to be made to this file.

1. Add the following to the top of the file, above or below the current set of {% set %} statements.

{% set contact_page_link_text %}{% trans %}the form that is shown at the default contact page; for example, <em>/contact</em>){% endtrans %}{% endset %}
{% set contact_page_link = render_var(help_route_link(contact_page_link_text, 'contact.site_page')) %}

2. Update the paragraph immediately following the <h2>Goal</h2> heading to:

<p>{% trans %}Set a site-wide contact form to be the default contact form ({{ contact_page_link }}).{% endtrans %}</p>

I've updated the issue summary's proposed resolution with this suggestion -- but discussion and feedback is welcome!

Edit: typo: show/shown

Edited issue summary's proposed resolution to fix typo (show => shown).

I reviewed the merge request via the generated Tugboat instance and I see that the HTML didn't get rendered properly, as you can see here (login: admin/admin)

https://mr3958-kxepnyr9mnydxhfgeg2mnr0rewij1yfl.tugboatqa.com/admin/help...

I think this is because there's HTML in the link text, so it gets escaped when passed through render_var(help_route_link()).

I'll do some testing and figure out a better suggestion.

Also, I rebased the MR to 10.1.x, but maybe the target branch needs be update to 11.x (I'm not sure).

I've pushed a fix after working out a solution. I've updated the issue summary. This is ready for review and testing.

Steps to test:

1. Use the "Live preview ready" via Tugboat link in this issue to review the merge request. Link
2. Login as admin/admin
3. Install Help Topics (admin/extend)
4. Navigate to admin/help
5. Click on the top-level topic, "Managing contact forms"
6. Under "Related topics", click on "Setting a default contact form" (admin/help/topic/contact.setting_default).

I'm working on rebasing onto 11.x.

First, I squashed the 3 commits and rebased 10.x.

Ok, looks like it's not necessary (or appropriate) for me to add this to the 11.x branch, since it's a minor bug fix that can go in to 10.1.x (hopefully). The tests are passing now after I rebased again, so this looks good for a final review.