This is the last piece of the core actions rewrite to enable multiple

views for the same actions.
Instead of assigning a single attachment point and parent ID to an

action, zero or more placements can now be assigned. A placement is an

ActionPlacement instance that sets:

The attachment point to render into
An optional parent action ID
An optional default renderer
An optional DOM element ID

This enables an action to (for example) be parented to a menu or another

group in one attachment point, and then a button or some other render in

another group.
Actions no longer fail to register when a placement fails. That is, if

an action is too deeply nested in one placement, it will still register,

since it can still be used in another (even if registered later via a

future extension hook).
At this point, we have 4 core concepts comprising the action system:


Actions, which contains the core metadata and client-side

   activation logic.


Action renderers, which render the HTML and JavaScript for an action

   in a given attachment point.


Attachment Points, which are a location in which actions can be

   placed, providing default renderers.


Placements, which define the Attachment Point configuration in which

   an Action would be rendered, and options governing that rendering.

Unit tests pass.
Tested that all actions worked as expected, including with in-progress

changes to consolidate the actions used for Quick Access.