feat: Update syntax of custom torch ops

[andrea-fasoli]

Description of the change

This PR updates the syntax of registration of a custom op with pytorch. The purpose of registration is to create a custom operation that can be inserted as custom node in the computational graph without inducing a graph break.

From PyTorch 2.4, new torch.library functions have been introduced:

• custom_op replacing impl
• register_fake replacing impl_abstract
  They streamline earlier implementations of the custom op registration process. With the new syntax, there is no need for an additional op definition using torch.library.define.

The earlier syntax is deprecated from PyTorch >= 2.6: impl_abstract redirects to register_fake and throws a warning.
However, the new functions introduce a severe lower bound to fms-mo-supported PyTorch versions (>= 2.4), so we may want to hold to this update until later on.

Was the PR tested

• I have ensured all unit tests pass

[chichun-charlie-liu]

can we use a "version check" approach like the one we used for external kernels here?

[andrea-fasoli]

addons updated with branching based on pytorch version.
There's some duplication of the version-dependent decorators between GPTQ and INT8. We can eventually move these to fms_mo/utils/aiu_utils.py and import them from there.
Notice FMS forces torch==2.5.1 at this time, so this version check is only relevant when FMS-MO is used independently from FMS.

[chichun-charlie-liu]

do we really need to pass pt_ver as an arg to this func? it can access torch_version defined on L27 directly. Unless there is a case we want to register using a syntax that is lower than the current installed PT version?

[andrea-fasoli]

pt_ver is not needed at this time but l plan to move these decorators somewhere under utils and import them (they are shared between gptq and int8), so I'd prefer for them to be more general and not force users to declare a global torch_version variable, even in future addons.