PreTrainedTokenizer.from_pretrained should be more general
I'm trying to implement a general interface to any of these transformer models in AllenNLP.  I would love to be able to do something like `PreTrainedTokenizer.from_pretrained(model_name)`, and have this work for any model name across any of your implemented models.  It looks like what needs to happen for this is to detect which underlying model is being requested, and pass off to that class's `_from_pretrained` method.  Does this make sense?  In particular, I think the thing that needs to change is here: https://github.com/huggingface/pytorch-transformers/blob/067923d3267325f525f4e46f357360c191ba562e/pytorch_transformers/tokenization_utils.py#L149-L151

It could be changed to something like:

```python
    @classmethod
    def from_pretrained(cls, pretrained_model_name_or_path, *inputs, **kwargs):
        if 'bert' in pretrained_model_name_or_path:
            # import BertTokenizer here to avoid circular dependencies
            return BertTokenizer._from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)
        # other cases here
        # default to existing behavior if we can't detect the model class
        return cls._from_pretrained(*inputs, **kwargs)
```

If this looks right to you, I can put together an initial PR for this.

It would be super helpful if there were similar functionality for models, too, but I haven't gotten far enough yet to worry about how exactly that would work =).
Yes, this is a nice idea, I was thinking about implementing something like this for another reason (simplifying the task of maintaining `torch.hub` configuration files).

Regarding the library architecture, I think it's better to make a new (very simple) class, something like `AutoTokenizer` in a new file `tokenizer_auto.py` deriving from `PreTrainedTokenizer` (no need to avoid circular dependencies in this case).

Then the idea would be to make a new file `modeling_auto.py` as well with something like `AutoModel`, pretty much like `AutoTokenizer`, and `AutoModelForSequenceClassification`, `AutoModelForQuestionAnswering` that would encapsulate standard architectures on top of each model.

Maybe the `AutoXXX` is not the best name, also thought about `GenericXXX` or `UniversalXXX` but they convey meanings that could be misleading.<|||||>`{Generic,Universal,Auto}` Tokenizer and Model interfaces would be awesome (I'm also highly interested in that, as I'm currently working on Flair to add support for all six architectures) :heart: <|||||>Ok, I've hacked something together for an internal hackathon this week.  I'll see if I can pick this up the way you suggest next week, if no one else gets to it first.  I also don't know much about your PR requirements, so if someone who's more familiar with this repo wants to pick it up, I wouldn't complain =).<|||||>This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
