Omit parameter names instead of marking as maybe unused.

The nElements parameter in readEnum is left, because the max number of
enum elements should be used in a future version, for better error
checking.

This way, the corrector names don't have to be duplicated in every
relevant module's req file.

This was only noticed due to an intermittent slowdown in the iocInit
call in stTIM.cmd.

This happened because asynEnumSyncIO.c's readOp() [1], called from
devAsynInt32.c's initBi(), loops *nIn times calling the asynPrint macro.
Uninitialized nIn could and did take arbitrary, sometimes large, values;
a perf report even showed most of the iocInit time was spent in the
getTraceMask() call of asynPrint. However, since tracing wasn't enabled
at that level for the port, it never tried to print anything, and didn't
trigger a segfault by accessing out-of-bounds memory.

[1] https://github.com/epics-modules/asyn/blob/R4-44/asyn/interfaces/asynEnumSyncIO.c#L155

With the removal of the DCC core, there is a big change to the available
channels.

The filter defined in fofb_shaper_filt has representation limits for its
coefficients, so an external multiplier gain might be necessary to
actually implement it in hardware. To avoid requiring an additional gain
in the hardware and the resultant resource consumption, it was decided
to use the FOFB accumulator gain implemented in hardware as the
combination of FOFBAccGain and FOFBAccFilterGain.

It is simpler to define the PV for it in fofb_processing, since it has
to be combined with the FOFBAccGain for the FOFBAccHwGain that's applied
to the hardware.

The output for FOFBAccHwGain is a -RB because it shouldn't be written
to, and is the configuration we tried to write to hardware. The input is
a -Mon because its sole purpose is getting a feedback as to what's
actually in hardware.

In order to provide feedback on the applied gain's precision, the
readback for the separate gains uses the gain that was actually applied
to hardware divided by the other gain's setpoint.

The slightly complex CALC definition for the gain readbacks is necessary
for two reasons: the readback will be different from the setpoint if the
resulting HwGain is outside of the hardware's representable range (this
can also be verified with FOFBAccHwGain-Mon's value); and one of the
gains being set to 0 shouldn't cause the readbacks to be NaN.

And add its PVs to autosave.