Add early stopping callback to pytorch trainer
# Summary

Address PyTorch half of https://github.com/huggingface/transformers/issues/4894 by adding early stopping patience and a minimum threshold metrics must improve to prevent early stopping. I piggybacked heavily off of https://github.com/huggingface/transformers/pull/7431/ since the two functions are very similar.

Since https://github.com/huggingface/transformers/pull/4186 seems to be abandoned and behind master, I figured I'd take a crack at this.

## Who can review?

Anyone! But @julien-c and @sgugger seem the most appropriate.
Hi there. Thanks your PR! When I was designing the callbacks, it was to be them small independent pieces of code. I would prefer if early stopping had its own callback that the user would then choose to add or not. Do you think you could amend your PR in that direction?<|||||>Hello, thank you for your feedback! I will amend the PR in that direction.

Could you clarify which pieces of early stopping should be in `TrainerState` and which should be in the callback? I'm grappling with the similarities between `best_model_checkpoint` and early stopping attributes.

```python
class EarlyStoppingCallback(TrainerCallback):
    best_metric: Optional[float] = None # maybe not this
    best_model_checkpoint: Optional[str] = None # maybe not this either
    early_stopping_patience: int = None
    early_stopping_patience_counter: int = None

    def on_evaluate(self, args, state, control, **kwargs):
        # Keep track of patience
        # End training via early stopping
        if (
            self.early_stopping_patience is not None
            and self.early_sotpping_patience_counter >= self.early_stopping_patience
        ):
            control.should_training_stop = True
```<|||||>Or do you mean I just move the if statement I added to its own callback and keep `TrainerState` as is?<|||||>The `TrainerState` shouldn't change, so the callback you are writing above sounds fine, without the arguments marked with `# maybe not this`, which should already be in the `TrainerState`, I think.
Does that sound right to you?<|||||>That makes sense. I think [this](https://github.com/huggingface/transformers/blob/e812753736f475b62849ef0e72149306408c1395/src/transformers/trainer.py#L910) block of code (to line 933) could be a callback because it's all about the best metric. Then users could customize the best model calculations. Is that desirable?

If you think that's out of scope I'll keep the early stopping callback simple and separate from the best metric calculation.<|||||>I had put it in `Trainer` because I thought multiple callbacks could need it and it's used by `load_best_model_at_end` which is kind of a core feature.<|||||>Sounds good, you know best! I keep `load_best_model_at_end` in the `Trainer` and push up an early stopping callback sometime this week.<|||||>Thanks for your thorough and affable review!