Flesh out fallback key logic

[DavidMcClatchey]

What needs to be done

Generate fallback keys for CDA elements in an eICR wherever a stable key or narrative key cannot be generated.
Currently in cda_fallback_keys.py. The main fallback methods are soft_context_key and secondary_discriminator.

Why it needs to be done

We need this for our core matching logic.

Acceptance Criteria

• Working with existing prototype code, review and refactor the code to generate a fallback key for sections that can neither be keyed by the stable_key method nor by narrative key methods. See cda_fallback_keys.py.

Technical Notes

• Development should be done on the david/prototype-diff branch to ensure new code still properly integrates with all of the prototype code that hasn't been fleshed out yet. Once this feature is complete, then a new branch should be created to merge only the files relevant to this feature into main.
• Double check if any of the methodology in the fallback keys is already overtaken, i.e. already handled, by any of the methodology of building a stable key or narrative key.

[DanielSass]

from refinement: want to talk more about this in eng sync

[DavidMcClatchey]

Double check if root extension method is duplicated somewhere else.