Improve accessibility of tour module

Accessibility review of Tour module, and some ideas for improvements.

Tour button in toolbar:

- "tour" label is kind-of informative, but could be better.
- ... an aria-describedby? Maybe to associate some help text like "show tips about important features on this page"
- ... indicate a dialog will appear with aria-has-popup="dialog"
- Now press it.
- when it has keyboard focus, activatin the button makes the tooltip appear, but focus is still on hte toolbar button. Sighted keyboard user can see the first tip, but effectively cannot advance to the next tip. Focus will move from tour toolbar button to user acount link. The actual tips are at the end of the document.
- Should move focus to start of dialog.
- For assitive tech, there's no indication that anything has happened. There is an aria-pressed="false", but this DOES NOT CHANGE when pressing it. With screen reader, when you arrive at the button, it says "tour, button, not pressed". Press it, the dialog appears, but focus remoans on the toolbar button, and the screen reader says "button, not pressed". Note, if
- We would expect it to announce a "dialog". Actually it has a dialog role, but it isn't announced because focus hasn't moved there. If you use a mouse when running a screen reader, you can hear the dilaog being announced. Press the toolbar button, then click inside the tooltip. The dialog role will be announced. So this will hopefully be OK if we move the focus when the tour is invoked.

Tip dialogs:

- There's no indication to assistive tech for "what is this tip pointing to?" The tooltip association is purely a visual indication. Not easy to solve this...
- basically, we're looking for the opposite of aria-descibedby. "This dialog describe such-and-such control".
- If a programatic associuation is not possible, then an invisible span could say this, e.g. the tooltip is pointing to the file upload button.
- If we can implement dialog role semantics, then the invisible "describes file upload button" could be at the start of the dialog, and maybe the ting that gets focus when a new tip appears.
- on dismissing dialog, where should focus go?
- return focus to where it was when tour was first invoked?
- or move focus to whatever thing is being described by the current tip? Would need to make it clear for assistive tech. Does the tip always point to a focusable control?
- WOuld expect ESCAPE key to dismiss a dialog. If a sighted keyboard user invokes the tour, they can't get past the first tip, and they can't dismiss it either.

Idea:
- indicate tour milestones in the UI, even when tour is not active. Like, some "what's this?" markers. Clicking one of those would invoke to tour, starting mid-way though, at the relevant tip. Metaphor: sightseeing bus tours in cities sell tickets which are valid for "hop on, hop off" use. This would be an alternative route to access the tour tips, whcih could be a lot easier to access for assistive tech users. (Compare with WCAG 2.0 "multiple ways", which isn't really about this scenario, but the principle still applies somewhat).
- It's only possible to move forward in the tour. Should moving backwards be an option? It would make sense to do this if we allow users to join the tour half-way though.

TODO:
- assess how this works with browser zoom, including mobile. Does it re-flow nicely, and preserve the visual association, with the speech-bubble-stalk in the right place? Go maximum zoom.
- assess how well this works for screen magnifiers
- CONFIRM: does WCAG 2.1 Content on Hover or Focus apply here? Seems it's neither of these things, since it's invoked with an explicit button press, and dismissed with an explicit button
- Compare with tooltip-dialog pattern in W3C WAI-ARIA authoring practices - is this relevant? If so, is there any behaviour we'd need to implement?
- Various forms of balloon help have been around in desktop OS for ages. Review how these work, to see if there are any a11y features that can be implemented in a webpage tour?
- assess whether each improvement needs changes in Drupal code, versus fixes in the upstream Joyride library.
- Add a focus style for the tour tip close button. We'll need that once we have the keyboard accessibility working. Use a square outline like the ones for our other dialogs, per #2863354: Add border to dialog [x] close button for hover and focus states.