feat: Let parents declare actions supported on their children

[mwcampbell]

The initial use case for this is the implementation of ScrollIntoView in Masonry, on the virtual-scroll-a11y branch. When given a choice between adding complexity in AccessKit and adding complexity in UI frameworks, I favor the former. In this case, the latter would mean that the Masonry core framework would have to add some way for the VirtualScroll widget to indicate that the ScrollIntoView action should be added on all of its children, even though the children can be of any widget type.

The reason for specifying that this applies to direct children in the filtered tree is that I want to leave open the possibility that a scroll widget could have an intermediate GenericContainer child (that gets filtered out) for the purpose of specifying the current scroll translation in just one place.

[DataTriny]

We have several tests in the common crate to cover action related methods on Node. Please use these as reference to test the new methods.

The documentation of these new methods talk about the filtered tree. It is not explained anywhere in the documentation so it's an internal implementation detail at the moment and I doubt it would make much sense to anyone reading this. I guess we need to explain this concept somewhere else and put links in here. Probably out of scope for this PR.