Defer `warp.config.*` resolution in `Module.__init__` by storing `None` and resolving on use

[shi-eric]

As done in #856 for the module-level "mode" option, we should replace direct reads of warp.config.* in Module.__init__()’s self.options with None placeholders.

When an option is used, resolve it dynamically: if the local value is None, fall back to the current global warp.config.* value. This decouples module construction from global state, improves reproducibility and testability, and allows late changes to warp.config to take effect without going through clumsy wp.set_module_options() calls.

This will result in a change in behavior for users that were relying on the current "snapshot" behavior.

[c0d1f1ed]

@shi-eric I've recently been refactoring config functionality (notably #1307) so I'll take a stab at this one too if you don't mind.

Detailed (preliminary) design: deferred-module-options.md

[shi-eric]

@shi-eric I've recently been refactoring config functionality (notably #1307) so I'll take a stab at this one too if you don't mind.

Detailed (preliminary) design: deferred-module-options.md

Sure. What wasn't captured in this issue is that we wanted something more ambitious about the enable_backward flag, which is a mess in the current codebase due to all the different places that might set the value of enable_backward.

A larger-scale refactoring might be needed so that most users never have to think about enable_backward. Instead, Warp should figure out when adjoint kernels are required, e.g. through the use of adjoint=True when calling wp.launch() or through the use of wp.Tape() when capturing a kernel launch in the forward pass. This might be filed in a separate issue, but I mainly wanted to clarify the intentions here.