Introduce sharded checkpointing for NO_SHARD FSDP.

Nobody has claimed this yet.

### Description & Motivation

My recent benchmarks of considerably large (yet, still fitting on single H100) model training at scale show that depending show that it can take 30-40s per model save. This overhead becomes increasingly problematic with growing scale nad the frequency of checkpoint saves - e.g for 256 devices, single checkpoint save would introduce ~2-2.5 hours of idle GPU time (even if the checkpoint is saved on only one worker, the others need to wait). This problem can be significantly reduced with the introduction of general shared checkpointing mechanism for NO_SHARD FSDP strategy - each of the workers would save only portion of the model, yielding reduced storage latency at the cost of single "allgather" operation on checkpoint load/restore.

### Pitch

The problem could be solve in two ways:
1) Extend FSDPStrategy to allow sharded checkpointing even for NO_SHARD strategy - the training process would not change, but sharding would be done only for checkpoint saving.
2) Extend ModelCheckpoint callback to support sharded checkpoint save / load.

### Alternatives

_No response_

### Additional context

_No response_

cc @borda @awaelchli @carmocca

Start by examining FSDPStrategy and the ModelCheckpoint callback, focusing on how the NO_SHARD strategy currently saves and restores checkpoints. Determine which proposed approach fits the project, then define completion as workers saving checkpoint portions independently and restoring them correctly with the required allgather behavior.

Written by the indexing model from the issue text.