Add support for optional conditioning in PatchInferer, SliceInferer, and SlidingWindowInferer

[FinnBehrendt]

Fixes #8220

Description

This PR adds support for optional conditioning in MONAI’s inferers, allowing models to receive auxiliary inputs for conditioning that are processed (patched, sliced) the same way as the inputs. This is particularly relevant for generative models like conditional GANs or DMs.

Example Usage:

# Given a conditioned model, inputs of shape (1, C, H, W, D) and condition of shape (1, C, H, W, D)
output = SliceInferer(...)(inputs, model, condition=cond_tensor)

Types of changes

• Extended PatchInferer, SliceInferer, and SlidingWindowInferer to optionally accept a condition tensor (passed as a kwarg).
• The condition can now be:
  • None (default)
  • A tensor of the same shape as inputs
• The inferers now slice/patch the conditions alongside the corresponding inputs and feed them to the network.
• Updated unit tests for each inferer:
  • Verified with and without conditioning

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
• Quick tests passed locally by running ./runtests.sh --quick --unittests --disttests.
• In-line docstrings updated.
• Documentation updated, tested make html command in the docs/ folder.

Additional extensions such as support for dense vector conditioning (e.g., (1, C, Z), with Z being the conditional dimension) could be explored in a follow-up PR if there’s interest.

[virginiafdez]

The PR looks good to me overall, with appropriate tests that pass. Not sure if it'll be better to derive the condition from an argument defaulted to None instead of kwargs, to be more transparent. If leaving to kwargs, I believe there should still be some mention on the dosctrings that it is possible to pass a "condition". Not sure about this either, but If the shape of both input and output have to match, then checking for this at the beginning of the inferer sampler would be good (+test).

[FinnBehrendt]

Thanks a lot for the suggestions! I just pushed the updated changes.