[Feature]: Add capability for seasonal offset in a CPUE catchability

[Rick-Methot-NOAA]

Describe the solution you would like.

I often see model configurations in which users create season-specific fleets in order to have season-specific Q, and sometimes season-specific selectivity. Most often, it is to get at season-specific Q. Addition of a capability to have season-specific Q would provide a more convenient and probably faster-executing option.

• review how seasonality in MGparms is implemented to see if extendable to Q
• consider generic capability to have seasonality in any parameter, especially selectivity parameters

Describe alternatives you have considered

The MGparm approach has specific input for each parameter type. If selected, then season parameters created to do:

     if (MGparm_seas_effects(j) > 0)
        {
          wtlen_seas(0, gp, j) = 0.0;
          for (s = 1; s <= nseas; s++)
          {
            wtlen_seas(s, gp, j) = mfexp(MGparm(MGparm_seas_effects(j) + s));

A feasible generic implementation could be:
if abs(Block_type_rd) > 10, then block_type = sign(block_type_rd) * (abs(Block_type_rd) - 10).
then value in tens place would be the control for seasonality. This allows seasonality to be in addition to blocks and trends on base parameter.
The use of abs and sign is because a negative block is the indicator for trend approach.

• count number of Q parameters that request seasonality
• for each of them, create a Q_seas(f,s) parameter.
• check to be sure float is off and check to see that one of the seasons has fixed Q_seas = 0.0 to be the base.
• implement the Q_seas in exp_val where Q as parameter code already is located
  https://vscode.dev/github/nmfs-stock-synthesis/stock-synthesis/blob/main/SS_expval.tpl#L398-L399
• Nice to have: check data to see which seasons have obs, then create parameter only for those seasons.

Statistical validity, if applicable

NA

Describe if this is needed for a management application

NA

Additional context

No response