Determine framework automatically before ONNX export
# What does this PR do?

Determines whether to use `torch` or `tf2onnx` as the ONNX exporter automatically with the following priority:
1. User input via `framework` / `--framework`.
2. If local checkpoint is provided, use the same framework as the checkpoint.
3. Available framework in environment, with priority given to PyTorch.

Fixes issue https://github.com/huggingface/transformers/issues/18495 where PyTorch was still attempted for a local TF checkpoint even though it did not exist in the environment. This also avoids requiring users to use `--framework=tf` when using the ONNX export driver script.

Misc:
* Adds `tf` to pip install for `run_tests_onnxruntime` and  `run_tests_onnxruntime_all` in CI.

## Tests
* `python -m transformers.onnx` driver with and without `--framework` on local checkpoints and hub. Tested in containerized environments that had only PyTorch, only TensorFlow, or both.
  * Successful.
* Unit tests: ran `RUN_SLOW=true pytest tests/onnx`
  ~~* Overall, tests **passed w.r.t `main`** since they share the same failing tests:~~
<strike>

```
FAILED tests/onnx/test_onnx.py::OnnxExportTestCase::test_quantize_pytorch - TypeError: 'module' object is not callable
FAILED tests/onnx/test_onnx.py::OnnxExportTestCase::test_quantize_tf - TypeError: 'module' object is not callable
FAILED tests/onnx/test_onnx_v2.py::OnnxExportTestCaseV2::test_pytorch_export_048_data2vec_vision_image_segmentation - ValueError: Unrecognized configuration class <class 'transformers.models.data2vec.configuration_data2vec_vision.Data2VecVisionConfig'> for this kind of AutoModel: AutoModelForImageSegmentation.
FAILED tests/onnx/test_onnx_v2.py::OnnxExportTestCaseV2::test_pytorch_export_on_cuda_048_data2vec_vision_image_segmentation - ValueError: Unrecognized configuration class <class 'transformers.models.data2vec.configuration_data2vec_vision.Data2VecVisionConfig'> for this kind of AutoModel: AutoModelForImageSegmentation.
```

</strike>

~~* Wrote up https://github.com/huggingface/transformers/issues/18614 for the `TypeError: 'module' object is not callable` errors.~~ **Fixed by https://github.com/huggingface/transformers/pull/18336**
~~* As for the `AutoModel` error, https://github.com/huggingface/transformers/blob/main/src/transformers/models/auto/modeling_auto.py#L363 says not to add new models, so is this failure acceptable?~~ **Fixed by https://github.com/huggingface/transformers/pull/18587**


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

@LysandreJik and others who may be interested :)

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @LysandreJik

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @n1t0, @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh

 -->

_The documentation is not available anymore as the PR was closed or merged._<|||||>> Thank you so much for greatly improving the framework selection in the ONNX exporter @rachthree (also, welcome as a first time contributor 🥳)!
> 
> Overall, the logic looks great to me and I'd really like to see a unit test of the `determine_framework` function. This would give us some confidence that any future changes on the framework selection side won't accidentally break the desired behaviour.
> 
> Regarding the failing unit tests, these will be fixed by:
> 
> * #18587
> * #18336
> 
> so we can rebase your branch on `main` once they're approved / merged (should be soon)

Thank you for the review and welcoming me! I'm excited to contribute, especially since this is my first PR in the open source community :)  Glad to see the 2 PRs will fix those unit tests. 