[OPT] Adds `GPT2TokenizerFast` to the list of tokenizer to use for OPT.
# What does this PR do?
Adresses the issues with OPT where `use_fast = True` does not use the Fast GPT2 tokenizer. 
A follow PR should add a warning when the Fast tokenizer is not available. 

This should allow people to do : 
```python 
>>> from transformers import AutoTokenizers
>>> tok = AutoTokenizer.from_pretrained("facebook/opt-1.3b", use_fast = True)
>>> tok.is_fast
True
```
_The documentation is not available anymore as the PR was closed or merged._<|||||>The previous tests were passing but the tokenizer was `slow` were it should have been `fast` 😅 <|||||>a gentle ping here, as the m4 group needs to have all official opt models to support fast tokenizers.

Thank you, @ArthurZucker!<|||||>Merging ASAP.<|||||>cc @ydshieh the failing tests are related to the length of the dictionary of the tokenizer. Spaces are encoded to `222`, which is then passed to the model, while the vocab and embeddings are smaller. I am probably gonna skip it WDYT?<|||||>> cc @ydshieh the failing tests are related to the length of the dictionary of the tokenizer. Spaces are encoded to `222`, which is then passed to the model, while the vocab and embeddings are smaller. I am probably gonna skip it WDYT?

Haven't looked this in very detail, but it looks like some bug exists in fast tokenizers. If this is really the case, I am not sure why we want to go ahead to enable the fast tokenizers (by skipping the failing tests).

But if I miss any context and saying any non-sense, please correct me.<|||||>The problem is not from the Fast tokenizer (it is a GPT2 tokenizer) but the tiny config test. 
GPT2TokenizerFast is pretty much full proof at this points. I was just wondering if you have a quick fix for this,  ( as I said, the tokenizer's  vocab lenght is `258` while the model tiny  expects no more than `99`, which is causing this issue. This just means that the initialisation of the tiny tokenizer is not correct for this test ( it is using OPT-350m). 
<|||||>Sir, the PR is based on a quite old commit on `main` (2 weeks ago). Could you rebase (well, better to use merge as you have already done `merge` previously) on `main`, and see if things go better/well.

FYI,  the pipeline testing has some (non-trivial) change(s) in the merged PR #20426.

Hint: it's always nice to rebase (or any way you prefer) to have new commits on `main` in a PR.<|||||>we can also re-do the tiny tokenizers if they don't conform with the needs of the CI.<|||||>As @ydshieh said it might have been fixed, the problem is that the CI is still kind of stuck/not working ... not really sure if it is only this PR, but otherwise should be good to merge<|||||>- pipeline test is fine
- torch test failed with `test_save_load_fast_init_to_base ` which is known to be flaky.

@ArthurZucker Could you check other failing tests - probably they are just flaky ones ..?
<|||||>I will run them locally 😉 <|||||>Good to go! <|||||>cc @stas00  sorry for the long wait<|||||>Thank you very much for taking care of this, Arthur!