Add option to not re-load the model when resuming from checkpoint.

### Feature request I'd like to have the option to get the trainer to resume_from_checkpoint *without* reloading the model. I propose adding a boolean option parameter: `without_checkpoint_model: bool = False`. Starting from a checkpoint with this parameter set to True would require that the model was supplied to the Trainer constructor (pretty standard practice anyway) and would simply skip this line of code in the Trainer: `self._load_from_checkpoint(resume_from_checkpoint)` @muellerzr , @pacman100, @amyeroberts ### Motivation When Trainer.train(resume_from_checkpoint=my_checkpoint) is called, the Trainer will attempt to re-load the model in the my_checkpoint directory during the resumption process. This is kind of wasteful but no big tragedy if the model in question in fully supported by Trainer. Right now, Trainer needs to know how to reload a model before it can be used with resume_from_checkpoint. This was (and may be still) a big problem for QLoRA model users who had to spend quite some time waiting for Trainer to be modified to specifically support re-loading QLoRA models. One could train these models from scratch just fine by loading them first and supplying them to the Trainer constructor, it was just impossible to resume_from_checkpoint with them. It looks like there is supposed support for resuming with QLoRA added very recently but then some folks complaining that it does not actually work in practice: - https://github.com/huggingface/transformers/issues/29607 - https://github.com/huggingface/transformers/issues/29383 But even if QLoRA reloading does work today or will soon, there is a wider problem. In general, whenever there is a new model type that the Trainer does not explicitly know how to load, it will be impossible to resume_from_checkpoint for that kind of model until support is added to Trainer for loading that type of model. Lots of new kinds of quantization and LoRA initialization methods are being invented all the time (e.g LoftQ). Do we…