LlamaTokenizer should follow signature of PreTrainedTokenizer
### Feature request

PreTrainedTokenizer has a signature such that if the eos/bos tokens shouldn't be applied, they're set to None in the constructor. LlamaTokenizer (which is a subclass of PreTrainedTokenizer) instead always sets these, and adds a `add_eos/bos_token` field to enable/disable them. This breaks code that depended on the behavior of the base class in order to detect how to form sequences, eg when doing custom tokenizations using `tokenizer(stuff, add_special_tokens=False)` to build pieces of a sequence and then manually adding the EOS/BOS tokens.

cc @zphang @ArthurZucker from git blame

### Motivation

-

### Your contribution

-
The default `eos_token` and `bos_tokens` are there because the `sentence piece` model has these set, which means we are following the `llama` implementation. Having `add_eos` and `add_beo` gives the flexibility of enabling the addition, while not having to set the tokens to do so. 
This might not fit your specific usage, but most of our tokenizer work that way! 
I am not sure I understand why it would break in your case, but you can easily set the `eos` and `bos` to `None`, the same goes with the `add_eos` and `add_bos` that you can set to `False`<|||||>This is even more confusing after I was told that the normal transformers tokenizers add CLS and SEP to sequences by default when `add_special_tokens=True`, but in this class, you're (optionally) instead adding BOS and EOS instead.

Simply setting eos/bos to None works, but a user isn't expecting to have to do this to get behavior that's compatible with the base class. And tokenization bugs tend to be very subtle and take a lot of time to track down - this issue didn't crash my code, it just silently inserted an extra token (which caused havoc downstream). The point of inheritance is that a subclass should have the same public interface as the parent, so that a user just has to conform with the interface of the parent and can expect all subclasses to just work. This isn't the case here. <|||||>Thanks for educating me on inheritance, I understand your use-case and how this can be confusing. The problem is that in order to keep the information of the content of these tokens, while not necessarily adding them prevents us from setting them to `None`. Indeed this breaks your code, but it also allows people to use the tokenizer in another way. They can decide whether to add or not the eos and bos depending on the usage. 

Overall it's a design choice and lots of other tokenizer don't respect this either. I am sorry that it broke your pipeline.<|||||>This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.