feat: Add data_detector_types attribute to FieldContent struct

[njausteve]

Title

Add data_detector_types attribute to FieldContent struct for automatic data detection

Type of Change

• New feature

Description

This pull request introduces the data_detector_types attribute to the FieldContent struct. This attribute allows developers to specify a list of detectors that automatically convert data such as phone numbers, URLs, addresses, or calendar events into tappable links. The change aligns with the goal of making the field's content more interactive.

Key Changes:

1. New Attribute:
   • Adds data_detector_types to the FieldContent struct with support for the following types:
     • "PKDataDetectorTypePhoneNumber"
     • "PKDataDetectorTypeLink"
     • "PKDataDetectorTypeAddress"
     • "PKDataDetectorTypeCalendarEvent"
2. Validator Updates:
   • A new validation function to verify that the data detectors are among the supported types.
3. Testing:
   • Added tests to ensure that the new attribute behaves as expected, including edge cases like nil and invalid detectors.

Testing

• Added unit tests to validate proper handling of data_detector_types, including:
  • Valid detector types.
  • Empty and nil cases.
  • Invalid detector types to trigger appropriate errors.

Impact

• Code Impact:

  • Changes are confined to the FieldContent struct and its validation logic in validators.ex.
  • Tests were added to ensure existing functionality remains unaffected.

• Performance Impact:

  • The performance overhead is minimal, as the changes are limited to additional validation checks during the creation of FieldContent instances.

• Behavior Impact:

  • No breaking changes. The new attribute is optional and defaults to nil for existing code.

Additional Information

The new data_detector_types attribute is fully optional and backward compatible. Invalid values are caught early by validation to prevent runtime issues.

Checklist

• My code adheres to the coding and style guidelines of the project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.

[njausteve]

closed #148