Allow registration of user callback invoked with each rendering

[SeanCurtis-TRI]

Allows the introduction of arbitrary code to be executed each time the render pass is evaluated.

The render_callback.html exercises the new functionality.

---

This change is 

[jwnimmer-tri]

Generally I would just remind you to take a step back and look at the big picture. This is a yak pile that's pretty deep, and far away from your actual objective. Lateral thinking might help you find less-general solutions that are closer at hand.

For example:

• Don't try to stream (push) the camera positions from the JS back to the C++. Instead, offer C++ a way to poll for any value from the JS side. The model visualizer can manually poll for what it needs.
• Use PoseSliders for both the camera position and camera target (instead of JointSliders).
• Write a better default dmd.yaml file for the scene you'd like to interrogate. Add multiple cameras for the multiple points of view you want to inspect. Don't try to do anything interactive.

[jwnimmer-tri]

That's what the render-time callback allows for now.

No, this current PR is push not poll.

[jwnimmer-tri]

This follows the 'get slider value" mechanism of reading values back from meshcat:

The difference is, the controls panel only sends a message when something changes. This (as used by the Drake PR) seems to send an incredibly high rate of messages (from all connected browsers).

It's not clear to me how to even achieve that as all communication is asynchronous.

See the prototype of image-fetching in https://github.com/RobotLocomotion/drake/issues/18912. The meshcat.cc sends a request and then waits for a reply with a busy-loop.

[jwnimmer-tri]

In any case, it probably make more sense to discuss this as part of the Drake PR, since that's the top-down view. I'll bounce over to there next.

[SeanCurtis-TRI]

Readme.md line 285 at r5 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

See https://github.com/jwnimmer-tri/drake/commits/20484-send-only-changed. There is _no reason_ to pass a `viewer` argument. Even with a string lambda, both `viewer` and `this` are in scope already. None of the other callbacks (e.g., buttons) have an argument.

So, essentially, we're promising that the viewer is available as this which puts constraints on when and how the javascript string gets evaluated. It seems so much saner to just pass the viewer. It's an easier promise to check.