Allow custom model loading behavior

Nobody has claimed this yet.

### Description & Motivation

I am facing two difficulties:
1. My lightning module takes another `torch.nn.Module` in its constructor. Modules or tensors shouldn't be logged as hyper-parameters, and so `MyModule.load_from_checkpoint(...)` fails for me.
2. I have multiple inheriting modules that provide the same functionality (similar training procedure, same evaluation, same base API), so I wish to load a model regardless of its actual type (for example, for checkpoint evaluation). However, I cannot call `BaseModel.load_from_checkpoint(...)` (obviously).

What I need is a way to customize the loaded module's creation. That is, if `pl.LightningModule.load_from_checkpoint` is like `__init__`, then we need the equivalent of `__new__`.

### Pitch

A solution to both cases could be a new class function/callback that replaces the default class creation (`obj = cls(**_cls_kwargs)` in `core.saving._load_state(...)` with a custom procedure. One possibility could be:

```python
class LightningModule(nn.Module):
...
@classmethod
def new_from_checkpoint_args(cls, checkpoint: Dict[str, Any], **kwargs):
return cls(**kwargs)
```

and instead of the aforementioned `obj = cls(**_cls_kwargs)` call, something along the lines of:

```python
creation_method = getattr(cls, 'new_from_checkpoint_args', None)
if creation_method is None:
obj = cls(**_cls_kwargs)
else:
obj = creation_method(checkpoint, **_cls_kwargs)
```

### Alternatives

Instead of using PL's checkpoint loading API, I had to wrap it with my own, and had to make some ugly bypasses.

### Additional context

Since the loading and saving of the model are part of the lightning-module's API (i.e. using the `on_load_checkpoint` and `on_save_checkpoint` callbacks), this functionality should also be part of the model's API.

cc @borda @awaelchli

Start with LightningModule.load_from_checkpoint and the obj = cls(**_cls_kwargs) creation path in core.saving._load_state(...). Review how checkpoint arguments, modules, and tensors are handled, then assess the proposed creation hook against both custom construction and loading an alternate subclass. Done means the loading API supports the requested customization without breaking existing behavior.

Written by the indexing model from the issue text.