Fix dynamic dispatch calls which are fully masked

[njroussel]

This PR fixes evaluted dynamic dispatches which are fully masked.

The return value (if there is one) of an evaluated dynamic dispatch which is fully masked is completely arbitrary in theory: it should never be used. In practice, JIT internals expect the return value to be properly initialized to something. The previous code would not initialize the return value, and would hence crash the user's script. This might seen like a corner case, but in reality it is extremely frequent when rendering in wavefront-mode with Mitsuba 3.

In this PR, the return value is zero-initialized, such that it is consistent with a symbolic dispatch. Python dr.dispatch statements make use of https://github.com/mitsuba-renderer/drjit-core/pull/86 to trace an arbitrary instance. This is necessary to figure out the return value type. Special care needs to be taken when calling a fully-masked target, even though it's return value won't be used it might still generate side-effects. Tests were added to check the new behavior.

[wjakob]

Am I understanding correctly that this fix is specific to Python? (The call to _peek occurs in the Python bindings). Does the issue not arise on the C++ side? Other than that, the changes look good to me.

[njroussel]

Not quite, it's a cascade of two things:

• Both in C++ and Python, there was an issue because the return value wasn't ever initialized.
• In C++ the return value can be initialized by using compile-time information. In Python we must use the registry_peek function because we can't resolve the return value's type from the list of target functions. We trigger this zero-initialization, in both C++ and Python, by passing nullptr as self in the callback function.

(Technically, we could use the registry_peek function in C++ too - at the cost of tracing a function rather than immediately returning zeros when self is set to nullptr. )

[wjakob]

Great. Returning zeros based on the known type is the way to go whenever possible.