Extending with Extension propagation policies

[jkiddo]

This pull request introduces a configurable policy for automatic extension propagation during PlanDefinition and ActivityDefinition application. The main changes add a new ExtensionPropagationPolicy interface, integrate it into the core CR processing pipeline, and update related processors to support fine-grained control over which extensions are copied. This enables users to customize extension handling, improving flexibility and safety in FHIR resource processing.

Extension Propagation Policy Integration

• Added the ExtensionPropagationPolicy interface with built-in policies (e.g., legacy, excludeUrls, allowOnlyUrls, none) to control which extensions are automatically copied during processing.
• Introduced the ExtensionPropagationContext record to provide context (extension URL, FHIR version, source/target paths) for policy evaluation.
• Updated CrSettings to include a configurable ExtensionPropagationPolicy, with getter, setter, and builder-style methods. [1] [2]

Processor Updates for Policy Support

• Refactored ExtensionProcessor to accept and use an ExtensionPropagationPolicy for filtering extensions; added methods for copying extensions with policy enforcement. [1] [2] [3]
• Modified constructors and usages of ApplyProcessor, ProcessAction, and ProcessGoal in both ActivityDefinition and PlanDefinition apply pipelines to accept and pass through the propagation policy. [1] [2] [3] [4]

Resource Conversion and Usage

• Updated goal conversion logic to use the new extension copying mechanism, ensuring only permitted extensions are propagated to goal targets. [1] [2]
• Adjusted extension processing calls in action processing to specify source and target element paths, supporting more precise policy decisions.

Pipeline and Settings Wiring

• Ensured that the propagation policy from CrSettings is passed through the initialization of all relevant processors in both ActivityDefinition and PlanDefinition pipelines. [1] [2]

These changes provide a robust and extensible mechanism for managing extension propagation, making the CR engine safer and more adaptable to different implementation requirements.

This is a first-round fix for #258

[jkiddo]

@JPercival this should address the issue you reported back in the days