Fix module compile for Fanatec driver

[coolbho3k]

@amstan noticed that with my last change, if you set CONFIG_HID_FTEC=m, the compile breaks. The compile was okay previously with CONFIG_HID_FTEC=y only, which was in the default config, so I didn't notice the problem.

This small PR fixes the compile when CONFIG_HID_FTEC=m.

Test plan

1. Tested first with no changes to the default config. The driver still initializes correctly.
2. Tested second with a kernel and module compiled with CONFIG_HID_FTEC=m. Did insmod hid-fanatec.ko and the driver initializes correctly.

[amstan]

Yeah, I updated my @MiSTerArch kernel config to match the latest version and my policy (both for misterarch and other kernels on arch or chromeos) has been that if an input device is not builtin to the hardware (eg: removable and unlikely to be present for everyone) the driver should stay a module, that's why i hit this problem. I know MiSTer's kernel defaults to a lot of stuff builtin though so I guess it doesn't matter much here, except for perhaps upstreaming attempt purposes.

I guess I could go moving more drivers (that are =y on mister) to modules, if anyone needs me to experiment with this. It would probably make the kernel image smaller and lower boot times.

[sorgelig]

Making many drivers in modules isn't a good idea as it greatly increase kernel footprint as each module has to include wrappers for each library separately while being built-in it's fused with less memory usage. Modules are also more fat than built-in which makes loading slower. It's also getting slower because loading happens only after file system gets ready. Making driver in a module is worth usually when it needs to load a firmware or needs to be activated on later stages.