Traced models serialization and torchscripting fix
# What does this PR do?

- Fixes the issue that was preventing traced models to be TorchScripted
- Fixes the issue that was preventing trace models serialization
- Fixes get_attr issues

Fixes #15974 

@jamesr66a Can you try on your end and validate that it solves your issues? 

_The documentation is not available anymore as the PR was closed or merged._<|||||>There seems to remain a few failures in `torch.fx` tests; the PR can be merged after those are solved!<|||||>@michaelbenayoun I'd like to propose some additional fixes that we discovered were needed to properly trace `T5ForConditionalGeneration`:

https://github.com/jamesr66a/transformers/commit/1a75148346cb471267b59fe7b473f304f6a02691

Can these be added?<|||||>Yes, for some reason the tests do not pass for torch 1.11 (I tested locally on torch 1.10).
I will add those changes too.<|||||>@michaelbenayoun Can I propose one final change to switch the graph surgery workaround to only trigger on older PyTorch versions where it's relevant?

https://github.com/jamesr66a/transformers/commit/5ac7bb737d9c9806051311a16f1799102d456fb8

Otherwise, when we're working on PyTorch nightly, this^ code breaks because it's trying to remove nodes that still have uses<|||||>@jamesr66a I added the gating, but only from version 1.12 as it was failing otherwise.<|||||>@michaelbenayoun Unfortunately, bumping the version check up to `1.12` breaks us. Actually, that was indirectly working around a semantic issue with deleting the concrete arg node. Do you mind augmenting the patch with this:

https://github.com/pbelevich/transformers/commit/e3fce52d1e14b1f75941fcaca7cd3029a6128016<|||||>@sgugger  Replaced the creation of a new flag by setting a special value for the `fx_compatible` flag for models that can be traced but not torchscipted (-1). 
This flag should take a boolean value 99% of the time anyways.<|||||>@michaelbenayoun This doesn't really work either. I'm not trying to be gratuitously painful here, but the common model tester is at the core of our test suite for the new model addition PRs. Those PRs are huge, and it only thanks to a robust CI that we can make sure the models added actually work with the whole API Transformers offers.

Adding a new flag, or a magic value for an existing flag, just because there is one model that needs different testing is not something we usually do or allow. In both cases, either the contributor or the reviewer will have no idea what your new flag/magic value does, especially since there is no documentation of it anywhere.

As I said before, in those instances where we need to adapt a common test to a specific model, we override it in the tester of said model. cc @LysandreJik and @patrickvonplaten 