Inconsistent values returned by batch_encode_plus and encode_plus 
## 🐛 Bug

<!-- Important information -->

Model I am using (Bert, XLNet....): Bert

Language I am using the model on (English, Chinese....): bert-base-uncased

The problem arise when using:
* batch_encode_plus and encode_plus with pad_to_max_length & max_length

## To Reproduce

Minimal exemple :

I compare tokens created via batch or not, and they are different for **masks** and **types**
```
pretrained = 'bert-base-uncased'
tokenizer = FixedAutoTokenizer.from_pretrained(pretrained)
model = AutoModel.from_pretrained(pretrained)
text = "My"
text1 = "features are ok"

mylist = list()
mylist.append(text)
mylist.append(text1)

#####################################################################################################
batch_encoding = tokenizer.batch_encode_plus(mylist,
                                             return_tensors='pt',
                                             add_special_tokens=False)

######################################################################################################
text_encoding = tokenizer.encode_plus(text,
                                      return_tensors='pt',
                                      add_special_tokens=False,
                                      max_length=3,
                                      pad_to_max_length=True)

print("\n--Batch Encoding \n")
print(batch_encoding['input_ids'])
print(batch_encoding['token_type_ids'])
print(batch_encoding['attention_mask'])
print("\n--One-by-one encoding\n")
print(text_encoding['input_ids'])
print(text_encoding['token_type_ids'])
print(text_encoding['attention_mask'])
```

It gives 

```
--Batch Encoding 

tensor([[2026,    0,    0],
        [2838, 2024, 7929]])
tensor([[0, 1, 1],
        [0, 0, 0]])
tensor([[1, 1, 1],
        [1, 1, 1]])

--One-by-one encoding

tensor([[2026,    0,    0]])
tensor([[0, 0, 0]])
tensor([[1, 0, 0]])
```

## Expected behavior

It should return the same value, like following 

```
--Batch Encoding 

tensor([[2026,    0,    0],
        [2838, 2024, 7929]])
tensor([[0, 0, 0],
        [0, 0, 0]])
tensor([[1, 0, 0],
        [1, 1, 1]])

--One-by-one encoding

tensor([[2026,    0,    0]])
tensor([[0, 0, 0]])
tensor([[1, 0, 0]])
```

## Environment

* OS: MacOs Mojave (reproduced also on Ubuntu)
* Python version: 3.7
* PyTorch version: torch==1.3.1
* PyTorch Transformers version (or branch): transformers==2.3.0
* Using GPU ? no 
I've been experimenting with `batch_encode_plus` with my current project and I have found few more inconsistencies and code affected:

* `batch_encode_plus` is not introduced in any tests, so it is hard to tell what was desired behavior of this method
* `batch_encode_plus` is not extending `encode_plus` in context of input parameters:
   * `encode_plus` is using input parameters like: `text, text_pair=None, add_special_tokens=True ...`
   * `batch_encode_plus` is using input parameters like: `batch_text_or_text_pairs=None, add_special_tokens=False ...`
* `batch_encode_plus` is not extending `encode_plus` in context of implementation logic, ie. is not reusing `prepare_for_model` as `encode_plus` (and `encode` via `encode_plus`), instead encoding is implemented in alternative way
* `batch_encode_plus` was used in pipleines https://github.com/huggingface/transformers/blob/eb59e9f70513b538d2174d4ea1efea7ba8554b58/src/transformers/pipelines.py#L426 in MR https://github.com/huggingface/transformers/pull/1548 which is currently in 2.3.0 release
* `batch_encode_plus` is used in https://github.com/huggingface/transformers/blob/335dd5e68a1b6ab6f51952c36a9ff6d8822c963f/examples/run_lm_finetuning.py#L135 on current master branch

Taking the inconsistency with `encode` and `encode_plus` it seems that above usage of `batch_encode_plus` can produce undesired output.

Also because of inconsistency I think that `batch_encode_plus` name is highly misleading and this method should be at least renamed to something like `batch_alternative_encode`.

Letting know @thomwolf, as he was reviewing #1548<|||||>@knuser agreed, whole implementation of batch_encode_plus is very different from encode_plus. I found it weird also but I am not aware of all different uses cases / features that it support. Anyway, I would like to you if you agree on the fact that encode_plus and batch_encode_plus should give the same results for same input as described in the ticket ?<|||||>I agree<|||||>I also experienced this inconsistency and it would be great if the problem can be fixed soon.