Reland "[views-ax] Migrate kName in OmniboxResultView"

Difference between this CL and the previous reverted CL:

This reland CL adds a call to update the accessible name from inside
the `OmniboxResultView::SetMatch` function.

The original CL was reverted due to a failing ChromeOS tast-test that
was checking the value of the OmniboxResultView nodes and found a stale
value for the node's accessible name. This is because the previous CL
only updated the accessible name in the cache when the node was selected.

OmniboxResultView objects are reused after their creation, and their
data is simply updated as the user types new input into the Omnibox.

The previous CL:1596671 removed the emission of name changed events from
inside of `SetMatch`, noting that although it's "arguably technically
correct" to emit the events as part of `SetMatch`, it is "noise to the
screen reader."

This solution worked while the assistive technologies were accessing
the node's accessible data through `GetAccessibleNodeData`, which would
calculate the accessible data in the moment.

This CL removes `GetAccessibleNodeData`, and that creates a necessity
to begin updating the accessible name as part of `SetMatch` again.

Screen readers and other ATs should not be making announcements due to
these events, unless the event is happening on the node that currently
has focus.

This updated CL updates the expectations in `EmitAccessibilityEvents` to
reflect the new patterns put in place here.

Original change's description:
> [views-ax] Migrate kName in OmniboxResultView
>
> This CL migrates the accessible name setter for OmniboxResultView from
> being calculated only when requested in `GetAccessibleNodeData`
> ("pull") to updating the value in the ViewAccessibility cache whenever
> it changes ("push").
>
> The logic that was used to calculate the name in
> `GetAccessibleNodeData` was moved to a new private method named
> `UpdateAccessibleName`, which gets called at time of construction,
> and when the result view's selection state changes, since the
> selection state can impact the value of the accessible name.
>
> `OmniboxPopupViewViewsTest.AccessibleResultName` is added to test
> this functionality.
>
> Because the accessible names are being added to the cache at the
> time of construction, and the selection state only changes the
> value of the accessible name in certain circumstances, we no
> longer expect a TextChanged event to be fired in the nominal
> case where the View's selected state changes. As such, this CL
> removes checks for the number of TextChanged events fired in
> `OmniboxPopupViewViewsTest.EmitAccessibilityEvents`.
>
> This CL also updates how current OmniboxPopupViewViewsTests get
> the value of the accessible name. Instead of using the
> `TestAXEventObserver` to get the accessible name every time a
> Selection event is fired (via `selected_option_name()`), the tests
> directly use `ViewAccessibility::GetAccessibleNodeData` to get the
> accessible node data from the cache as needed. This follows the test
> patterns we are using throughout the Views code as part of the ViewsAX
> project to mock AT behavior.
>
> This change is part of the ViewsAX project:
> https://docs.google.com/document/d/1Ku7HOyDsiZem1yaV6ccZ-tz3lO2XR2NEcm8HjR6d-VY/edit
>
> Bug: 325137417
> Change-Id: I67e719566e4d5b5497f29c66a30fd041cffb8e29
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5906787
> Reviewed-by: Taylor Bergquist
> Reviewed-by: Patrick Noland
> Reviewed-by: Javier Contreras
> Commit-Queue: Evelynn Kaplan
> Cr-Commit-Position: refs/heads/main@{#1368482}

Bug: 325137417, 373588159
Change-Id: I8cb5833358d7157389fef9fa67c759459774eb2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5938109
Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Commit-Queue: Evelynn Kaplan <evelynn.kaplan@microsoft.com>
Reviewed-by: Patrick Noland <pnoland@chromium.org>
Reviewed-by: Tzarial <zork@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1379243}