Trainer push to hub
# What does this PR do?

This PR begins the work to completely integrate the `Trainer` API with the [model hub](https://huggingface.co/models). It introduces a new mixin `PushToHubMixin` that implements the `push_to_hub` method. That mixin is then subclassed in all objects have a `save_pretrained` method: config, tokenizers, models.

This enables the current API to create a new repo and push the model to it:
```
# Will create and push to https://huggingface.co/usernam/model_id/
model.save_pretrained(model_id, push_to_hub=True)
```
This requires the user to have a valid token, for instance generated by `transformers-cli login` (a useful error message is displayed if that is not the case).

If the repo already exists and the user just wants to update the weights, they can do:
```
model.save_pretrained(model_id, push_to_hub=True, repo_url=my_repo_url)
```
This will work as long as the git credentials of the user are stored locally. If not, a token may need to be passed either with `use_auth_token=True` or `use_auth_token=str_token`.

This also works to update the config or the tokenizer if there is a fix needed:
```
config = AutoConfig.from_pretrained(repo_id)
config.that_arg = fix
config.save_pretrained(local_folder, push_to_hub=True, repo_url=my_repo_url)
```

This PR also adds `Trainer.push_model_to_hub` that can be called after training to push the underlying model to the hub. This is controlled by a new `--push_to_hub` training argument, this last method is called in every example script using the Trainer, so people can start interacting with it.

Follow-up PRs scheduled are:
- have the Trainer automatically generate a sensible model card that can be pushed with the rest
- add the option to upload not only the final model to the hub but all checkpoints, using the versioning system to make it easy to navigate.

In terms of tests, this PR also adds a new environment variable watched by the Transformers library to decide which base url use in all things `from_pretrained`, which allows us to check the things we push to the staging env are actually working with the `from_pretrained` methods. The `tests_git_lfs` job in circle CI is renamed `tests_hub` and activates that env variable then runs all the tests marked with `is_staging_test` (which basically push things to the hub and check they can be used with `from_pretrained`).
Side note, the torchhub test uses the master branch to check which dependency to install (see [here](https://github.com/huggingface/transformers/blob/c0328a6c263494fff527fac7288faa627e3267e0/.github/workflows/github-torch-hub.yml#L36)), which means it can't pass until this PR is merged. Unless I missed something!<|||||>This is awesome - very much looking forward to have this feature! 

One thing I'd love to discuss are that they are 4 input arguments to to the `push_to_hub(...)` method - do we really need all of those? 

1.) I actually wouldn't put `save_directory` as an argument to `push_to_hub` because I think only the object on which `push_to_hub(...)` is called should be uploaded and not files that are unrelated to the object on which `push_to_hub()` is called. 

*E.g.*: If I call `model.save_pretrained("name/of/dir")` the model and config is saved in this dir => I would therefore expect `model.push_to_hub("name_of_repo")` to upload only model to the hub. IMO, this is more intuitive and more concise with how we design `save_pretrained(...)`. I don't really understand why a model object should be responsible to upload files to the hub that are not related to the model itself. Similar to how we call `model.save_pretrained(...)` and `tokenizer.save_pretrained(...)` to save everything we need, we should have to call `model.push_to_hub(...)` and `tokenizer.push_to_hub(...)` IMO.

2.) Also, I think it would be a bit nicer if we could reduce the args: `repo_name`, `repo_url`, `organization` to just `repo_name` and `organization`. I would make `repo_name` mandatory (by default it will be pushed under one's namespace) and `organization` optionally. Do we really need three args to define the repo URL? What do you think?


I feel quite strongly about 1.) to have consistency in the library, less strongly about 2.)