When actions were first built, we had a one-to-one mapping of action

class to UI representation. This changed with the introduction of the

Quick Access actions, which required duplicating and specializing

actions.
We only had basic forms of menu and menu item actions at that time, but

as we adopt actions for more parts of the UI (including page navigation

soon) that can show up in multiple places, we've needed a more flexible

approach.
Now, actions provide the metadata and, client-side, activation logic

(implemented in a former change), and rendering is handled by a separate

set of renderer classes. These are responsible for taking a registered

action and turning it into a UI representation server-side. These may be

buttons, menus, menu items, sidebar items, or something specialized for

any part of the UI.
Renderers don't need to be registered anywhere. They can be created and

then set as either the default for an action, or passed explicitly

during action rendering, which will yield new HTML/JavaScript for that

action's view.
Compatibility with existing action-driven rendering is still provided,

but deprecated and will be removed in Review Board 9. As of this change,

such actions are still using the legacy behavior, in part to aid in

testing this compatibility. These will be updated in another change.
This is a precursor to change that will provide defaults for different

areas on a page, which will make it even easier to reuse actions across

a page.

Unit tests passed.
Tested all actions used in the UI, making sure they rendered and

activated correctly.