[s2s] test_distributed_eval
This PR:

* [x] adds a helper function `get_gpu_count()`, which returns the number of available gpus (regardless of whether torch or tf is used) (otherwise we have to do all the `if _torch_available: import torch` rigmarole. 
* [x] adds a basic test for `run_distributed_eval.py`

Things I wasn't sure about:
- I put the new test into `test_seq2seq_examples_multi_gpu.py`, but it doesn't require multigpu. should I create a new test file  `test_seq2seq_examples_gpu.py` or just leave it here for now and refactor once we have more tests like this?
- I made it `@slow`, but wasn't 100% sure - it takes some 25s - probably too slow.

Fixes: #8297

@sshleifer 
Fyi the example tests don't currently run on the multi-gpu setup, as pretty much none of the examples tests were made to run on a multi-gpu setup.

We can look into adding them to the CI.<|||||>> Fyi the example tests don't currently run on the multi-gpu setup, as pretty much none of the examples tests were made to run on a multi-gpu setup.
> 
> We can look into adding them to the CI.

Absolutely!

Do you prefer to start with a CI job that explicitly lists tests that were converted to run on multi-gpu (3 at the moment) or just run them all? It's all that `require_torch_mutigpu` plus ` that `require_torch_gpu` as it's flexible.<|||||>> Do you prefer to start with a CI job that explicitly lists tests that were converted to run on multi-gpu (3 at the moment) or just run them all? It's all that require_torch_mutigpu plus that `require_torch_gpu` as it's flexible.

I would send a PR with whatever you think makes most sense. Or wait until the correct answer is clearer. At this point you know pretty much as much about CI tradeoffs as I do :)<|||||>I will prepare a new PR for github CIs.

otherwise I think this PR is complete.