Tokenizer encoding functions don't support 'left' and 'right' values for `pad_to_max_length`
## 🐛 Bug

In the tokenizer encoding functions (`encode`, `encode_plus`, etc.), it seems `pad_to_max_length` only supports boolean values. In the [documentation](https://github.com/huggingface/transformers/blob/master/src/transformers/tokenization_utils.py#L801-L805), it's mentioned it can also be set to `left` or `right`, but in the [code](https://github.com/huggingface/transformers/blob/master/src/transformers/tokenization_utils.py#L1151-L1162) these values are never checked for -- it's assumed that it's a boolean.

A simple illustration:
```python
>>> from transformers import BertTokenizer
>>> tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')
>>> text = 'Eiffel Tower'
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length=False))
[101, 1041, 13355, 2884, 3578, 102]
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length=True))
[101, 1041, 13355, 2884, 3578, 102, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length='left'))
[101, 1041, 13355, 2884, 3578, 102, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length='right'))
[101, 1041, 13355, 2884, 3578, 102, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
```
Thanks.
Hi, the documentation could definitely be improved in that regard but what the docstring means is that it will follow the class attribute `padding_side`:

```py
>>> from transformers import BertTokenizer
>>> tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')
>>> text = 'Eiffel Tower'
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length=False))
[101, 1041, 13355, 2884, 3578, 102]
>>> print(tokenizer.encode(text, max_length=20, pad_to_max_length=True))
[101, 1041, 13355, 2884, 3578, 102, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> tokenizer.padding_side = 'left'
>>>  print(tokenizer.encode(text, max_length=20, pad_to_max_length=True))
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 101, 1041, 13355, 2884, 3578, 102]
```
<|||||>I slightly modified the documentation in 9aeb0b9 and c024ab9
<|||||>Ahh, gotcha. Thanks for such a quick response! On a related note, would it not be better (to maintain consistency) to have the `padding_side` as an argument for `encode()` instead of setting it as a class attribute? We're providing the rest of them all inside the function.<|||||>Well padding side is more of a model attribute than an encode functionality. Some models were pre-trained with a padding side on the right (e.g. BERT, GPT-2) while others (e.g. XLNet) pad on the left, and need to be padded on the left in order to obtain coherent results.

Having it as a tokenizer attribute allows to set model-relative defaults, while allowing a change if need be!<|||||>That's a good point. I guess what I had in mind is to have that param in the function as well, besides it being a class attribute -- just like
`max_length` -- to which a similar rationale applies (and it defaults to the model default). But it's not really that important, I guess you guys have more important things to do like bringing out those insanely fast tokenizers. :)