Copter, Plane: persist the fixed notch conversion to INS_HNTC2

[andyp1per]

Summary

INS_HNTC2_MODE and INS_HNTC2_HMNCS are applied as defaults inside the pre-4.2 fixed-notch conversion, gated on the notch being disabled. Defaults are not stored, so the gate closes the moment INS_HNTC2_ENABLE is saved and both parameters revert to their table defaults on the next boot. Two consequences: a vehicle upgrading from 4.1 gets its converted fixed notch turned into a throttle-tracking notch on all harmonics one reboot later, and anyone setting HNTC2 up as a static notch sees MODE go 0 -> 1 across a reboot and has to set it explicitly to make it stick.

Save the values instead, and only when an old fixed notch was actually converted.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Tested manually, description below (e.g. SITL)

SITL A/B against a synthesised pre-4.2 eeprom holding the old fixed notch (INS_NOTCH_ENABLE=1 ATT=30 FREQ=95 BW=25):

	boot that converts	next reboot
before	MODE 0, HMNCS 1	MODE 1, HMNCS 3
after	MODE 0, HMNCS 1	MODE 0, HMNCS 1

Separately, on a wiped eeprom: enabling INS_HNTC2_ENABLE and rebooting used to move INS_HNTC2_MODE from 0 to 1 and INS_HNTC2_HMNCS from 1 to 3. Both are now stable across reboots.

Description

The intent of the two set_default_by_name() calls was to make a notch converted from the old fixed INS_NOTCH_ come up as a static notch on the first harmonic. That intent is correct, but expressing it as a default makes the effective default depend on the runtime value of another parameter, and it is never persisted, so it evaporates as soon as the conversion saves INS_HNTC2_ENABLE.

This deliberately does not make INS_HNTC2_MODE default to 0 in general. That would match what a GCS shows while the notch is off, and it would let a defaults.parm configure a static HNTC2 with ENABLE alone, but it would also silently switch every vehicle currently flying HNTC2 with an unsaved MODE from throttle tracking to static. The documented default has always been 1, since the parameter tables are what param_parse reads, so this makes behaviour match the documentation rather than changing anyone's filter configuration in the field.