[run_glue] Add MNLI compatible mode
In this PR:

- Upgrade `datasets` to `1.3.0`
- Rename `datasets` variable to `task_datasets` in `run_glue.py` to avoid confusion with the library `datasets`
- Add a `--mnli_compat_mode` option to use the old label assignment for MNLI
The CI failed but it seems irrelevant. Could you please give it a check? @LysandreJik <|||||>The CI issue is with `test_hf_api`, which is fixed on master now, rebasing should make the CI green!<|||||>@sgugger Sorry but I can't really agree with you here. It is a problem introduced by mistake and we shouldn't just try to ignore or downplay that. It just adds a few lines of if-else and I don't think it'll add too much burden for users. I can add some comments if it helps explain the code.

I am never a fan of trainer-style code since IMO in the context of ML, capsulation is not simplicity, instead, transparency is simplicity (I believe our user survey supports my claim here). Thus, I don't think our example here is meant for beginners at all. Besides, I do think back-compatibility matters especially when our success depends heavily on the prosperity of the model hub. This PR is meant to fix a bug though it's harsh. I want the users won't feel confused when they load a community model and wonder why it doesn't work. (Because I myself spent one whole day debugging this)


Happy to have more discussion here.<|||||>So we discussed it a bit more internally. This particular example script will stay as is with the backward-compatibility problem (which isn't one IMO since the problem is in the model config not having the right labels). As I said before it's an example aimed at data scientists that shouldn't necessarily have all the functionality.

There will be another script for GLUE (probably by the end of the month) very soon that doesn't use `Trainer` and has the training loop exposed, where we can integrate your fix.<|||||>Looking forward to the new script you mentioned!