Preserves compatibility with existing invokeActions call in button widget by creating a separate 'invokeActionCall' function to carry out the recursion. Triggering all descendants permits use of action widgets inside list widgets or macros. Also makes it possible to add triggering capability to select widget.
There are still some warnings about making functions in a loop, but
I’ll fix those as a separate pull request because the fixes are more
than typographic errors.
Previously, widgets were reading variables from themselves or their
cascaded ancestors. That means that if a widget sets a variable and
then reads the same variable, it will get the same variable back. That
sounds reasonable, until you consider a widget that wants to modify a
variable - eg the tiddler macro. For example:
```
<$tiddler tiddler={{!!report}}>
<$transclude mode="block" />
</$tiddler>
```
Here we first evaluate the `{{!!report}}` reference, which involves
reading the currentTiddler variable, looking up the tiddler, and
retrieving it’s `report` field. The next the tiddler widget is
refreshed, it will use the newly set currentTiddler as the basis for
resolving the `{{!!reference}}` reference.
The fix is to get variables from ancestors, but continue to set them on
ourselves.
Because:
* It doesn't work well with TW5's refresh mechanism, which relies on
being able to regenerate any portion of the DOM as required; this
frequently causes inline handlers to be re-executed at unexpected times
(see
http://tiddlywiki.com/static/TiddlyWiki%2520for%2520Developers.html)
* It mixes TW5 version-specific JavaScript with user content
* In multiuser environments there is a security risk to importing or
viewing tiddlers you didn't author if they can have JavaScript in them
One consequence of wikifying macro attributes before use was that we
couldn’t have tiddler titles with wikitext syntax in, which was
definitely a problem.
