Add a new unstyledButton css helper to output html `<button>` that do
not have any style. It allows us to easily replace clickable-but-not
kb-focusable divs with actual buttons, with basically no work to do on
the visuals, since those reset buttons kinda look like divs by default.

The intent behind using actual html button tags is that they are
keyboard-friendly by default, making us not having to specifically code
keyboard-specific stuff so that they work correctly.

the "…" menu of each workspace was only attainable with the mouse on
hover. Now we correctly show the dots also on keyboard focus ; and make
sure they can be focused themselves (by using a button tag).

we also add an alt text on the dots menu to help screen reader users

we will certainly want to create unstyled `<a>`, `<ul>`, etc. Just keep
those in the same file

one way to navigate with a screen reader is by going from html region to
html region. Most common region elements are header, nav, main, footer.
This adds a few region elements on specific parts of the app.

This also changes the role of some of our Region (our way of calling the
main app sections that we can cycle through with kb). The main region is
now a correct main role, and the top panel is now a header.

a `<a>` was used without href, making it non keybaord focusable. we
shouldn't use a `<a>` here anyway, as this acts as a button. using a
button tag makes it kb accessible.

the better way to resolve this would be to have only one "help center"
link instead of two next to each other, but i'm not sure of all the
implications (mobile view, customization, etc). So just add an alt text
for the icon-only link.

this makes undo/redo/notifications/share buttons focusable

and add some alt text for screen readers

use actual heading elements (or role=heading elements, same result)

- add a hidden heading so that SR users can quickly go to the documents
list
- make sure the "no docs" image is ignored by SRs
- make sure the headings row of docs (name/workspace/edited) is ignored
by SRs, it's no use on its own
- use ul+li tags on the doc list, that makes SR users able to quickly
navigate around it

- using one big `<a>` tag wrapping the whole row is not that great for
SR users as it gets pretty difficult to understand each part of the row.

now the link is actually only on the doc name, but the whole row is
still clickable thanks to a "stretchableLink" helper (taken from
bootstrap)

- adding some hidden "workspace" text before each workspace to help SR
users understand context

- hiding the doc icon from SR users as its purely decorative

- make the document dots button targettable through keyboard +
understandable for SR users

in a recent previous commit we made it possible to use keyboard to
target the "…" menu of each workspace in the left panel.

this was great but didn't really take care of screen reader users. The
`<a>` wrapping the `<button>` caused issues.

The html structure was reworked so that the whole row is not an html
`<a>` tag anymore.

Now the row is a div, containing a `<a>` (link to workspace), and a
`<button>` (dots menu) next to each other. The `<a>` tag is still
clickable on the whole row thanks to "stretched link" css.

this has the downside of generating new translation strings for the same
things but at least the code is better : i'll update translation strings
myself later in the translation app

- i'd say describing what the button actually is first, and then its
context, is a better order

thanks George!

with the few layout changes on doc list to improve keyboard navigation,
I broke the mobile layout by forgetting to add an `href` on the
mobile-specific doc names.

before, we added padding only when focusing items to easily have clear
focus rings without impacting too much code/layout.

that was not such a great idea, we'd rather have layout not shift at
all. For that, we add padding on the doc list name (anchors) and refine
margins around them (gaps/line right margin). Make sure to handle the
mobile specific doc name anchors also.

on the homepage, the doc list header is sticky positioned, making the
normal main panel focus ring go below it. Handle that specific case by
setting a top border on the sticky doc header div when the main panel is
focused.

the focus ring is a tiny bit better visually now that it doesn't try to
render out of the topbar (because the topbar hides overflowing stuff)