Restore is_torch_fx_available for trust_remote_code backwards compatibility

[MaybeSam05]

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).
• Did you read the contributor guideline,
  Pull Request section?
• Was this discussed/approved via a Github issue or the forum? 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, and
  here are tips on formatting docstrings.
• 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.

[Cyrilvallez]

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)

[HAN-oQo]

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:

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.