Updata tokenization_auto.py
Updata tokenization_auto.py to handle Inherited config class.
If ConfigB is inherited from ConfigA, then isinstance(ConfigB(), ConfigA) is true. We hope to use TokenizerB, but TokenizerA will be used incorrectly.

Hi, we have this [test](https://github.com/huggingface/transformers/blob/master/tests/test_configuration_auto.py#L45) to prevent exactly this. In what situation did you face an issue?<|||||>@LysandreJik There is no problem for pretrained models of huggingface transformers, because the config class of them are inherited from "PretrainedConfig". However, for users who want to add new models, their self-defined config class may be inherited from config class of some existing pretrained models. For example, I am trying to add a new model based on "BART" and my NewBartConig is inherited from "BartConig". My new tokenizer will not be used because a “NewBartConig” object is an instance of "BartConig" and bart tokenizer will be used incorrectly.<|||||>Yes, but we have similar issues with models, for example the `RobertaModel` inherits from `BertModel`. The test I mentioned above checks that (the example here is for configurations but we have the same test for models and tokenizers).

Currently the way to make sure your tokenizer is used and not the one on which it's depending is to put your tokenizer above the one it's inheriting from in the mapping. The for loop will then see this one first and use this one instead of the next one.<|||||>@LysandreJik Changing the order of items in TOKENIZER_MAPPING can solve the problem indeed. But get the rid of mapping order is more user-friendly, right? Close the pull request if you don't think the pr is necessary. Thanks for the review