Generalize (re)render method

[markus-walther]

The static render and rerender methods of <sig-nal> are great, except for when we want to do more than assign to a property of a DOM node.

Take the case of manipulating the .classList property: instead of assignment, you choose a method (e.g. toggle) and supply a parameter (the class name as a string literal), then invoke said method.

We can generalize things if we can supply an optional transform function (default: the existing assignment).

The new rerender(transform) signature would be backwards incompatible with respect to existing hydration specs: we would now need to specify rerender() function application in all those places where hydration specs previously used just rerender, i.e. mere reference to the function without. application.

The classList case would use e.g.

rerender(({domNode, name, signal}) => domNode[name].toggle(signal.value))

Think this through a bit more.

Then implement it!

[cloudspeech]

It seems better w.r.t. backwards compatibility and simplicity for simple cases to not extend rerender.

Instead, I propose to implement a new method renderWith({type,name, signal, signals, init, kind, domNode, domNodes, e) => / callback body /).

The classList case would then be

renderWith(({domNode, name, signal}) => domNode[name].toggle(signal.value))