MacViews a11y: Announce omnibox suggestions on keyboard navigation

Currently, when a user is navigating the omnibox suggestion list, we send two (handled)
accessibility events:
- Value changed
- Selection changed (that is: the empty selection at the end of the text is in a different
position because the string is a different length).

On macOS, the "value changed" event is not triggering an announcement. However, the "selection
change" event does, which causes odd behavior: the system reads a substring of a stale value,
typically the previously selected suggestion. Safari behaves in a similar way, so I think this
is less us doing something wrong and more VoiceOver being quirky.

This change invokes an explicit announcement of the suggestion text, similar to how it's currently
handled in Cocoa.

To facilitate this, this change adds a new Mac-only[1] code path to the views accessibility system
that allows directly specifying text for an accessibility announcement. Alternatives considered:
- Always announcing text field value changes explicitly. This is probably overkill.
- Adding a new native event to ax::mojom::Event to allow for sending arbitrary announcements.
This has the problem that events can't carry arguments so there needs to either be some implicit
convention for which attribute the announcement text is from, or extensive special casing every
time an announcement is added.

In practice, some substrings still get read from the selection announcement, but we have no
straightforward way to suppress it. However, the suggestions are now read in full, so the
impact from the noise is relatively small.

[1] Mac-only due to time constraints since the linked bug is RBS.


Bug: 863887
Change-Id: Iff220dff63e327d864bd5e5fbeb4523fab37bd94
Reviewed-on: https://chromium-review.googlesource.com/1142031
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576640}
7 files changed