[Whisper Tokenizer] Encode timestamps
Author: sanchit-gandhi
Pull request: yes

# What does this PR do?

As described in #24476, we have uploaded the Whisper timestamp tokens to the tokenizers on the Hub. This requires updating of the Whisper tokenizer and tokenizer tests to handle the new added tokens

cc @ydshieh @ArthurZucker 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

BTW, do we expect this changes showing up on users' code results? I think it's yes, but wondering why it is OK?

Alright refactored the tokenizer a bit to maintain the same results as what we had before! Essentially, we only output the timestamp tokens if the user passes `decode_with_timestamps=True`. Otherwise, we filter them out from the token ids, maintaining the behaviour we had before where the `.decode` method skipped them since they were OOV.

Previously, when the timestamps were not in the vocab:
* `decode_with_timestamps=False`: timestamp tokens skipped from the `.decode` method since they're OOV
* `decode_with_timestamps=True`: timestamp tokens manually added by the `._decode_with_timestamps` method

Now, the timestamps are in the vocab:
* `decode_with_timestamps=False`: timestamp tokens filtered out from within the `.decode` method (they're in-vocabulary now, so aren't automatically skipped)
* `decode_with_timestamps=True`: timestamp tokens added automatically in the `.decode` method

How does this look to you @ArthurZucker @ydshieh?

Sound good to me. Arthur will know better and can provide better comments in any I believe.

The tests pass for me locally, but a small subset of the fast tokenizer tests timeout on the CI: [link](https://circleci-tasks-prod.s3.us-east-1.amazonaws.com/forks/storage/artifacts/d5b57382-7f67-4274-9623-7f238ef4fb6f/457033993/b3e236a7-4839-4737-93fe-06b96ad1c060/0/~/transformers/reports/tests_torch/failures_short.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAQVFQINEODXMLOC25%2F20230912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230912T165951Z&X-Amz-Expires=60&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEDEaCXVzLWVhc3QtMSJHMEUCIAiUyw6JJaKlAyhx09NvNyD%2Bim9IwhgucrLVaP6eEZXtAiEAuWI9NcS7UXgP02B8VwaXXx15XCCU9%2BKPXJ%2BSZ%2FuAD1kqqwIIGhADGgwwNDU0NjY4MDY1NTYiDDzx64NrLY3vyLDcmCqIAuc%2BpK0RmEy8pRmLia3gseKKbhKOZ%2B66iDdeDxAEjnEApGprS28lsDHSM5xYcSI6KyQk%2B3%2Bk3tCOsX%2Bz6VbWbZM5Tn7Wpc1t6R5NUjPl%2BggOj8c%2BstRFvA0hRgacjs%2FB%2Bvj0ATnulS3ZeKUhe9vh2ubO0EuuBdp8dJ5js4eIfa711UqH6bWEVeMVss5N8aFWCyAZu0am9EIlRGR5C1xiIkkuzYdLvcY1R%2FmUXxL3TNX9lBVvyFCOS4l0yJ0u9iTyoan%2FGTO4UQMvsOQulq8TdmvsyWGwcju8cz37PqP%2F59%2B8dwVnxwU2tHLzmpqyRW5hPMf6t9WSK0r08Ix330ZKuxOyBsnwk3Ll3zDMsYKoBjqdAbY5dhwaoWcPQRpCrURiJdnd2LBtRCjGbffIm0B1exweCcdh0ZiBo7vG9xUBV%2BIJDpv8APP55re0ep%2FAg21T7b2DfWLDMm7jN8rgig0jzXIFOPqdLL1pSkgz32enWfC%2FPYunTtsT%2BEVCWTLnylp1K2iYgeKnCzSFtON0%2FEPOjgZ58FFFQjL%2BDaglGc9HhFcHhKUnArLwL0ODN%2FFgqEM%3D&X-Amz-SignedHeaders=host&x-id=GetObject&X-Amz-Signature=ea2518c3fc7e1bfe60b8c83a36c320fdf0c01c416e87dd1d0f272727ea7c72de)

=> any reason these tests should timeout now that we have the expanded vocabulary with the new added tokens? It seems to me that it's the same stage that always gets stuck:
https://github.com/huggingface/transformers/blob/8f609ab9e00e99b05fe2463483748c1f664295d1/src/transformers/tokenization_utils_fast.py#L281-L282

Yeah works pretty well: after the first cache step, tokenizing decode is on-par with what we had before. 

That's correct regarding only computing the cache once: we'll likely never actually have to re-compute the cache, since in practice, everyone will used a fixed time-precision of `0.02`. However, the code can handle multiple values of time-precision, which is stay consistent with the `.decode` method where we allow `time_precision` as an arg