Converter: derive choices from the explicit type ceiling, not slice names

[ryukzak]

• Derive the choice declaration's choices from the explicit ElementDefinition.type ceiling only — never from slice names. When a profile's differential does not restate the element's type list, choices is omitted entirely.
• Slice variants are still materialized as choiceOf elements with their constraints; slicing.rules and discriminator stay on the declaration.
• New tests: untyped open-sliced root (no choices), typed open-sliced root (ceiling choices incl. unsliced variants), untyped closed-sliced root (no choices; rules: closed + variants are the prohibition signal).

Motivation: slicing a choice under rules: open constrains the sliced variants without restricting the choice, but merging slice names into choices made that indistinguishable from a genuine type restriction. Downstream consumers (atomic-ehr/codegen) falsely prohibited unsliced variants for open profiles — the KBV Basis cases reported in atomic-ehr/codegen#196.

Before (KBV_PR_Base_Condition_Diagnosis.onset[x], open slicing, no type restatement):

"onset": {
  "choices": ["onsetPeriod", "onsetRange", "onsetDateTime", "onsetAge"],
  "slicing": { "discriminator": [{ "type": "type", "path": "$this" }], "rules": "open" }
}

After:

"onset": {
  "slicing": { "discriminator": [{ "type": "type", "path": "$this" }], "rules": "open" }
}

Consumers inherit the base ceiling (onsetString stays permitted). Verified end-to-end against atomic-ehr/codegen: the full codegen suite passes unchanged, and the KBV profile resolves to all five base variants with nothing prohibited.