Update pt flax equivalence tests in pt
Author: ydshieh
Pull request: yes

# What does this PR do?

Update the PT/Flax equivalence in PT common test script.

This PR should be merged after #16298 and #16301 (then the test should be all green).


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

For `BigBird` model test failure, please see #16310. 


Good for me to merge then here as everybody else seems to agree with the PR.

I do like the argument that centralized tests enforce the same API which is very important to the library! 

However, I don't think we do this currently in many tests, e.g. `test_attention_outputs` is far from enforcing the same API by statements like those: https://github.com/huggingface/transformers/blob/9badcecf694f174da929bcfe668ca57851960ad8/tests/test_modeling_common.py#L566 or https://github.com/huggingface/transformers/blob/9badcecf694f174da929bcfe668ca57851960ad8/tests/test_modeling_common.py#L459
The same tests can pass many different output attention shapes.

The same holds true for: `test_headmasking`, `test_hidden_states_output`, `test_retain_grad_hidden_states_attentions` and pretty much every test that has an `if is_encoder_decoder` statement (to a big part I'm responsible for this hacks actually, but don't think it's the right approach).

So, if we go down the road of centralized testing than we we should probably be to clean up those tests and create larger `Mixin` Testers for `EncoderDecoder`, `Encoder-only`, `Vision`, `Speech`, ...

Still worried about readability & making it more difficult to add a new model in this case and also want to note here that IMO we rarely change the core functionality of modeling code once it's been added - our philosophy goes against it. E.g. as discussed new features like rotational position embeddings should **not** be added to existing models. Therefore I think it's not that much of a problem that tests might diverge

Here some of my thoughts:

1. in this particular place, I was able to use `super` because the (logic) difference (check the class and to keep or skip testing) doesn't depend on the code in the actual testing code (the one in `super` here).
2. for other places, like [here](https://github.com/huggingface/transformers/blob/f5e8c9bdeab96c3426583cf1aa572ce7ede8a070/tests/gpt2/test_modeling_flax_gpt2.py#L233), without changing the design, I think we won't be able to call super (or not in an easy way)
3. I think most of the cases will be case 2., so this PR using `super` is just a special case. **We would very likely to continue the `# overwrite from common since ..` for most cases.**
4. The `copy from` won't be very helpful I think when a common test is changed. For example, in PR #16301, a more thorough Flax common test didn't detect issues in `FlaxXGLM` (and I had the wrong impression all PT/Flax equivalence tests passed).
  Of course, this is probably the responsibility to keep this in mind that some tests are overwritten.
5. (for model, because there is no `common model`, so we are able to use `copy from ...`)
6. Regarding readability, (personally) I sometimes found it is not easy to understand what are the difference in the testing code between the common one and the model specific one. (Although I didn't find cases where this causes real problems in the library)



Thank you for all the discussion, I will merge this PR as it is (after rebase and make sure tests green).
It is nice we have this chance to discuss the design 🔥.
Think a further discussion is needed if we want to make some (big) change(s) mentioned in @patrickvonplaten comment.


> So, if we go down the road of centralized testing than we we should probably be to clean up those tests and create larger Mixin Testers for EncoderDecoder, Encoder-only, Vision, Speech, ...

This is the way to make tests more readable while making sure the reviewers have it easy when looking at new model additions, so definitely the right solution IMO! Note that the large mixin tests should be able to inherit most tests from the core mixin, but they would just overwrite the ones where we currently have an `if is_encoder_decoder` (or things like that).