Add tf_keras imports to prepare for Keras 3
Author: Rocketknight1
Pull request: yes

Keras 3 will break backward compatibility for our TF code, and is becoming the default Keras in TF 2.16. This PR uses the `tf_keras` package to maintain backward compatibility - it imports tf_keras if available, and if not then it attempts to import keras, but raises an issue if the version is >= 3.

Our future plan is to ensure that TF code remains backward compatible, but to support Keras 3 in all its framework-independent glory with new Keras classes (e.g. `TFBertModel` -> `KerasBertModel`). The PR for this is at #26224, but it's on hold until we handle the urgent issue of preserving backward compatibility. It was also blocked by the need for a couple of other PRs, but those are mostly in now. Because the full Keras 3 PR will require TF models to be rewritten with 100% Keras ops instead of TF ones, we'll likely need to do a community push once the core modelling code is ready to port everything.

cc @fchollet

Fixes #27377 
Fixes #28296

TODO:
- [X] Replace `keras` or `tf.keras` with `tf_keras` falling back to `keras` in core modelling code
- [x] Replace `keras` or `tf.keras` with `tf_keras` falling back to `keras` in all model files 
- [x] Confirm versions - should we reject Keras >= 3, or Keras >= 2.16?

Comments:
Quick note to myself: The failing test is likely caused by replacing `K.set_value()` with `tf.assign()` somewhere, since `tf.assign()` lacks an implicit dtype cast. The test fails whether or not other tests are run beforehand, so it's not a case of the mixed precision policy accidentally carrying over between tests (which happened to us before)

Quick note for @amyeroberts: Although there are a lot of changes in this PR, the core idea is simple, we `import tf_keras as keras` if possible, and if not we fall back to `import keras` and raise an error if the version is >= 3. To avoid copying the boilerplate all over the modeling files, I just do it once in `modeling_tf_utils` and then `from modeling_tf_utils import keras` in all files, but that's probably bad - let me know if you want me to just copy the import try/except block around instead!

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_28588). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@Rocketknight1 Have you run the slow model tests on this branch? 

I haven't, but I'll try it with a few models today!

Quick update @amyeroberts - I tested a couple of models with TF 2.14 + Keras 2.14, as well as TF 2.15 + Keras 3. Behaviour was as expected - the TF 2.15 run threw an error and asked me to pip install the `tf-keras` backwards compatibility package. After that was installed, the slow tests all passed.

@amyeroberts all comments should be addressed now! The last issue is the pytest stuff that should be resolved by rebasing once the PR for it is merged.

In case this isn't already on your radar, just wanted to let you know that the changes in this PR now cause an error for an import like `from transformers import AdamWeightDecay`. The error is:
```
RuntimeError: Failed to import transformers.optimization_tf because of the following error (look up to see its traceback):
module 'keras.optimizers.schedules' has no attribute 'LearningRateSchedule'
```
I'm guessing due to the change in these lines here: https://github.com/huggingface/transformers/blob/main/src/transformers/optimization_tf.py#L32
https://github.com/huggingface/transformers/blob/main/src/transformers/optimization_tf.py#L215
(so more generally, the error comes up with `from transformers import optimization_tf` too)

It looks like changing `keras.optimizers.schedules.LearningRateSchedule` to `keras.optimizers.schedules.learning_rate_schedule.LearningRateSchedule` might fix it?

good catch! Would you like to open a PR for a fix @echan5 ? 

Thanks for the warning @echan5! This is quite urgent, I'm on it, and I'm surprised our tests didn't catch it!

Thank you @Rocketknight1! (sorry, I didn't get a chance to get to it earlier)