Revise pid_process_denom default logic - second try

Revise pid_process_denom default logic - second try
This is a revision and partial revert of #9545.

While the previous version improved the behavior for non-8K gyros, it had some unfortunate side effects on the defaults and how they affected the output of the `diff`. Basically the problem is that in most cases the default value will end up getting adjusted during the first boot to work with the default low-speed motor protocol ONESHOT125. So if an appropriate default was originally set (like in the other PR) it shows up changed in the `diff` with default settings. The only workaround is to set the default to be the expected "corrected" value when ONESHOT125 is taken into account. This unfortunately reverts to the not so great behavior for gyros that have a sample rate < 8K, but that's unavoidable.

The inappropriate logic based on the `USE_` for various gyros being defined is still removed. This makes no sense in the unified targets context and was trying to determine if there's an SPI-connected gyro so that means it's going to run at 8K, but if not then it's going to be I2C and 2K, etc. This no longer makes sense.