Refactor InProgressScanActionType to use shared enum-value resolver

[kadraman]

Enhancement Request

Replace ad-hoc display/value handling in InProgressScanActionType with the shared resolver (IFoDEnumValueSupplier.resolveEnumValue(...)) to eliminate duplication, improve input matching robustness, and make enum behavior consistent across FoD enums.

Other potential useful refactors for maintainability:

• Extract large FoDEnums.java into multiple top-level enum classes (one file per related enum or per domain), e.g.:
  • InProgressScanActionType.java
  • DeveloperStatusType.java
  • AuditorStatusType.java
  • TimeZones.java
    This improves navigability and reduces merge conflicts.
• Standardize enum APIs:
  • Use consistent method names: getValue() for the canonical display string, or getDisplayName() where appropriate.
  • For enums representing external IDs, consistently expose getId() or getInternalValue() (instead of mixed _val, fodInternalValue, etc.).
• Introduce additional generic helpers:
  IFoDEnumValueSupplier already covers string/display resolution—consider adding IFoDEnumIntSupplier for enums that map to ints (to centralize fromInt patterns).
• Convert enums that use toString() custom logic to expose explicit getDisplay() and keep toString() either delegating to getDisplay() or left default with clear Javadoc.
• Add focused unit tests for each enum's parsing/resolution behavior (name->value, display->value, invalid inputs).
  Lint/format and add Javadoc for each enum explaining intended external representation and matching rules.
• Replace ad-hoc switch-based fromInt with small reusable helpers where it makes sense (but avoid over-abstracting simple cases).