modeling files loaded when they aren't being asked to be loaded
Author: stas00
Pull request: no

```
  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/trainer_seq2seq.py", line 22, in <module>
    from .trainer import Trainer
  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/trainer.py", line 65, in <module>
    from .trainer import Trainer
  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/trainer.py", line 65, in <module>
    from .models.auto.modeling_auto import MODEL_FOR_QUESTION_ANSWERING_MAPPING
      File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/models/auto/modeling_auto.py", line 214, in <module>
from .models.auto.modeling_auto import MODEL_FOR_QUESTION_ANSWERING_MAPPING
  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/models/auto/modeling_auto.py", line 214, in <module>
    from ..tapas.modeling_tapas import (
    from ..tapas.modeling_tapas import (  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/models/tapas/modeling_tapas.py", line 51, in <module>

  File "/gpfsdswork/projects/rech/ajs/uiz98zp/stas/transformers-master/src/transformers/models/tapas/modeling_tapas.py", line 51, in <module>
    from torch_scatter import scatter
      File "/gpfslocalsup/pub/anaconda-py3/2020.02/envs/pytorch-gpu-1.7.1/lib/python3.7/site-packages/torch_scatter/__init__.py", line 12, in <module>
```

Do we have to load `models/tapas/modeling_tapas.py` when we aren't using `tapas`?

There is some unrelated problem that gets triggered by this model loading `torch_scatter`, which is a 3rd party module.

I figured out the solution to the problem it triggered (binary incompatible `torch_scatter`), but still it might be a good idea not to pre-load model files until they are needed.

@LysandreJik, @sgugger 


Comments:
I'm not sure there is a way to workaround `Trainer` loading all models since it needs the `MODEL_FOR_QUESTION_ANSWERING_MAPPING` to get the names of the labels (those models have different label names that are not `labels`). The auto models then loads every model in the lib, which we can't work around without rewriting the module and its logic from scratch.

If I look at the code it's just:

```
MODEL_FOR_QUESTION_ANSWERING_MAPPING = OrderedDict(
    [
        # Model for Question Answering mapping
        (ConvBertConfig, ConvBertForQuestionAnswering),
        (LEDConfig, LEDForQuestionAnswering),
        (DistilBertConfig, DistilBertForQuestionAnswering),
        (AlbertConfig, AlbertForQuestionAnswering),
[...]
        (IBertConfig, IBertForQuestionAnswering),
    ]
```

why does it need to load all models in order to access this dict?

I understand that it is doing it now, but why can't it be in a separate file which doesn't load all models? e.g. in `trainer.py`:
```
from .models.auto.modeling_auto_maps_only import MODEL_FOR_QUESTION_ANSWERING_MAPPING
```
and inside `models.auto.modeling_auto_maps`
```
from .models.auto.modeling_auto_maps_only import MODEL_FOR_QUESTION_ANSWERING_MAPPING
```

Ah, right, because it doesn't know what those symbols are without loading all these models... duh!

Ok, so what you're saying it could have been done in a different way that doesn't require loading models - e.g. class names as strings but it'd require a big redesign.

OK, so since we are auto-generating code anyway during `make style`, we could autogenerate a simple dict with:
```
QA_model_classes = (
    'transformers.models.albert.modeling_albert.AlbertForQuestionAnswering', 
    'transformers.models.led.modeling_albert.LEDForQuestionAnswering', 
    ...
)
```
and then in trainer:
```
        default_label_names = (
            ["start_positions", "end_positions"]
            if self.model.__class__ in QA_model_classes
            else ["labels"]
        )
```
and there is no longer a need to load all models.

That would probably work yes.