[`tests`] add `accelerate` marker
# What does this PR do?

This PR introduces a nice utils for users and contributors (such as myself) that want to run just `accelerate` specific tests. Thanks to @fxmarty that has introduced to me this util

By using `pytest.mark` you can run `accelerate`-specific tests easily. With this PR, if let's say I want to run `accelerate` tests on OPT I can just do:
```bash
RUN_SLOW=1 pytest -m accelerate_tests tests/models/opt/test_modeling_opt.py 
```

cc @ydshieh @sgugger 

_The documentation is not available anymore as the PR was closed or merged._<|||||>Thanks @younesbelkada ! I understand the advantage of adding this. However, I would recommend to follow what we have like `is_pt_tf_cross_test` as in
https://github.com/huggingface/transformers/blob/619d51e01f326d298687912d1f65f8d460f2a6e2/src/transformers/testing_utils.py#L150
Along this approach, you also have to check

https://github.com/huggingface/transformers/blob/619d51e01f326d298687912d1f65f8d460f2a6e2/src/transformers/testing_utils.py#L142
and
(I am not familiar with this part hoever)
https://github.com/huggingface/transformers/blob/619d51e01f326d298687912d1f65f8d460f2a6e2/conftest.py#L34

This is a suggestion based my intuition - I never did this before in `transformers`. You can wait a bit to hear what @sgugger says.
<|||||>Thanks a lot for sharing that! 
I agree for consistency it would make sense to do this, however this solution seems IMO much simpler, given the number of affected tests (usually for each model there are only 3 `accelerate` tests), let's see what @sgugger will say!<|||||>> Thanks a lot for sharing that! I agree for consistency it would make sense to do this, however this solution seems IMO much simpler, given the number of affected tests (usually for each model there are only 3 `accelerate` tests)

My response here is not to convince @younesbelkada the suggested approach, but just want to point out the above argument doesn't seem very valid: if you look  `tests/test_modeling_common.py`, there is only one test decorated with `is_pt_tf_cross_test`, and yet we still use that approach.<|||||>The difference with the PT/TF cross tests is that we want to skip them unless a special env var is set (to not run them in the torch job and tf job for instance). This is not necessary here since as we don't want to prevent those tests from running in the regular jobs, this is just for convenience.<|||||>The failing test seems to be unrelated to this PR, merging!