The new rb-c-menu/RB.MenuView component had a few design decisions

made early on that, upon further reflection, weren't really necessary,

and impacted other parts of the UI.
It used display: block/none to control visibility, for a couple

reasons that made sense earlier in development, but weren't ultimately

needed. Since display cannot be animated, and affected animations, it

was up to RB.MenuView to more closely manage the opening/closing

states, adding some JS-specific intermediary classes to turn display

on/off at the right times. This actually broke the legacy .menu class,

which broke opening review request action menus.
Addressing this was actually pretty easy, and allowed for the deletion

of a lot of code. We're now once again using visibility and opacity

to fully manage the display. The JS intermediary state classes are now

gone, and all the setTimeout calls in RB.MenuView are gone as well.

This also allowed RB.MenuView.open() and close() to consolidate

fully into _setOpened().
It also fixes an issue with the key bindings. Previously, RB.MenuView

captured all keyboard events, with the idea being that while you're

interacting with a menu, you shouldn't be triggering other elements

accidentally. That ended up not working as well in practice. This

prevented things like jumping to another part of the UI via a keyboard

shortcut (posing an accessibility issue), or even reloading the page.

It no longer swallows all events, only preventing default behavior and

bubbling if the event is being specifically handled by the menu.

Unit tests pass.
Tested both mouse-based and keyboard-based navigation and usage of the

menu. Verified that keyboard-based navigation didn't animate the menu

(ensuring that capability hasn't broken).
Tested that the review request action menus worked.