Restore is_torch_fx_available for trust_remote_code backwards compatibility
Author: MaybeSam05
Pull request: yes

# What does this PR do?

Restores `is_torch_fx_available` in `transformers.utils.import_utils` as a backwards-compatibility shim so that Hub models loaded with `trust_remote_code=True` that still import this symbol no longer raise `ImportError` on Transformers v5+.

**Context:** In v5, `is_torch_fx_available` was removed from `import_utils`. Many community models (e.g. `deepseek-ai/deepseek-moe-16b-base`) ship their own `modeling_*.py` and still do `from transformers.utils.import_utils import is_torch_fx_available`, which breaks at import time when using v5.

**Changes:**
- Re-add `is_torch_fx_available()` in `src/transformers/utils/import_utils.py`.
- The function emits a one-time `DeprecationWarning` (via `@lru_cache`), returns `False` if PyTorch is not available, and otherwise checks that `torch.fx` can be imported and returns `True`/`False`.
- Under the v5 requirement (PyTorch >= 2.4), `torch.fx` is always available, so behavior for existing callers is unchanged.

Fixes #44561

## 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#create-a-pull-request),
      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).
- [ ] Did you write any new necessary tests?


## Who can review?

@ArthurZucker @Rocketknight1 — this restores a symbol removed in v5 that breaks `trust_remote_code` models (see #44561). Optional: @CyrilVallez for model-loading/import-utils context.

Comments:
cc @ArthurZucker wdyt? We could consider reintroducing, but IMO a bit pointless as again we cannot guarantee BC for remote models, and it's bound to broke in another way soon (if it's not already broken in another fashion already)

This is a real, currently-occurring issue outside just the specific example in the PR description — hit it independently while testing vLLM's Transformers backend (`--model-impl transformers`) with `deepseek-ai/DeepSeek-V2-Lite` on `transformers==5.13.0` (ROCm/MI250, but the failure itself is platform-independent — pure Python import error).

**Repro:**
```bash
pip install "transformers==5.13.0" "vllm>=0.25.0"
vllm serve deepseek-ai/DeepSeek-V2-Lite --model-impl transformers --trust-remote-code
```

**Error:**
```
ImportError: cannot import name 'is_torch_fx_available' from 'transformers.utils.import_utils'
  (raised from DeepSeek-V2-Lite's own modeling_deepseek.py:56, its trust_remote_code file)
```

`--model-impl vllm` (vLLM's native model implementation) doesn't hit this, since it never imports the model's remote code — only `--model-impl transformers` does, since it dispatches straight to `AutoModel.from_config(..., trust_remote_code=True)`.

Re: @Cyrilvallez's point that this is "bound to break in another way soon" — that's a fair concern in general, but for this specific symbol it's a real, present blocker for at least one actively-used model family (DeepSeek-V2/V2-Lite's remote code, which is still widely referenced from the Hub). Happy to help test this patch against our repro if that's useful signal for reconsidering.