TF Bert inference - support `np.ndarray` optional arguments
# What does this PR do?

This PR allows running inference with TF Bert when the optional arguments (such as `attention_mask`) are a `np.ndarray`. Although these changes were made in response to particular issues, which were related to TF Bert, other models have the same pattern (e.g. [here](https://github.com/huggingface/transformers/blob/master/src/transformers/models/gpt2/modeling_tf_gpt2.py#L413)), so these changes may positively impact other models too.

EDIT: see root cause [here](https://github.com/huggingface/transformers/pull/15074#issuecomment-1009133852)

Fixes #14346 and #14404 


Thanks for your changes, @gante! I think here we should add a TensorFlow common test to ensure that all models pass it, rather than adding a test for BERT only

Any test defined in this class will be run by all models:
https://github.com/huggingface/transformers/blob/9fbf7c87c37e32152428f91038bd46e04a48868e/tests/test_modeling_tf_common.py#L103<|||||>Agree with @LysandreJik - good PR that fixes an important issue, but a common TF test is better than a BERT-specific test!<|||||>That was a great suggestion, as it led me to the root cause of the issue! We already had a general test for numpy inputs (as you can see in the new diff), which was passing, but it failed if we passed the same inputs as keyword arguments. 

After some digging, I found out it was because Keras converts whatever is in the first argument of a layer to a `tf.Tensor` ([here](https://github.com/keras-team/keras/blob/master/keras/engine/base_layer.py#L1041)), so the packed numpy input in the test was converted to a tensor -- in other words, for Bert, `attention_mask` was a tensor in this setting. With an unpacked input, only the first input was converted, and thus the error in the issues surfaced.

The updated PR tests the issue for all TF models (we might discover new issues 😬 ) and fixes the error related to `shape_list`, but we might want to reconsider how we handle inputs to HF Keras models in the future :) <|||||>This seems to be another situation where there was a difference depending on whether the input was packed in the first argument or not (see [this issue](https://github.com/huggingface/huggingface_hub/issues/582#issuecomment-1008960808))<|||||>@Rocketknight1 / @LysandreJik -- can I get a review (or better yet, an approval)? :)<|||||>I just reviewed this - it looks great to me. Catching the issue with the conversion of the first argument was well done too.