Our actions framework got a huge rewrite in Review Board 8. While migrating

RBCommons over to Review Board 8, I noticed that the actions there were broken.

The way that we built the RBCommons extension actions closely resembled the

pre-RB8 action code. It's very likely to that actions built by extension

authors out in the wild were similarly built based off of the existing

action code. 
So this means that it's likely that other actions will be broken on Review

Board 8 too until authors modernize them. We should still support legacy

actions through its deprecation cycle, so this change does 3 things to

achieve that:

Return a useful value in BaseAction.get_dom_element_id().

In RB8 this method is deprecated and we changed it to return an empty string.

However, its likely that legacy action templates call

action.get_dom_element_id() because this is what we used to do in most all

of our legacy action templates. Now we look at the action's placement (which

for legacy actions, there will only be one because legacy actions only

support single-placement) and build an element ID that matches the element

IDs set by the modern framework's renderers. Now

action.get_dom_element_id() called in a template will match the DOM

element ID set in the renderer context.
We're careful not to use BaseAction.get_dom_element_id() as a default in

the renderers, unless the action subclass overrode it. That ensures we're

still using the right DOM element ID for multi-placement actions.
We also wrap the method in func_deprecated so that we show deprecation

warnings when someone calls the method from a template. Previously a

deprecation warning would only show up if a class overrode the method.

Move the JS view data backwards compat shim to the base action renderer.

DefaultActionRenderer.get_js_view_data() exists for backwards compatibility,

forwarding the legacy BaseAction.get_js_view_data() data to the action view.

We move this into BaseActionRenderer instead so that all actions benefit

from this regardless of what renderer they use.

Hide redundant child elements when building Ink menus.

Menu actions in RB8 are rendered as Ink menus, where the JavaScript view

builds the menu items from each child action's model data and leaves the

child's own rendered element in the DOM as an unused reference. This only

works if that element is hidden, which modern menu templates handle by

rendering children inside a hidden container.
However, legacy menu templates render their children inline and visible

(this is what our pre-RB8 menu template and the RBCommons account menu

both do). So now we hide the child's element in the menu view after

building it. This is a no-op for modern templates, since those children

are already hidden, and it keeps legacy menu templates working without

modification.
These changes allow us to support legacy actions, while also making sure

everything works with modern actions.

Ran RBCommons with the legacy actions and RB8. The logged in menu actions and

  logged out header actions both work.
Ran RBCommons with modern actions and RB8. The logged in menu actions and

  logged out header actions both work.
Ran unit tests.
Ran JS unit tests.