Create pattern to support multiple output formats

[diehlbw]

Overview

For integrtation and reuse by external tools, such as medHELM, it is useful to have an accessible resolve_prompt that has instruction sets for both "score-only" (like PDSQI-9) and "score + explanation" (like Summary of Care).
Further the expectation of these being nested dictionaries {"grade": int, "explanation": str} is more aligned with their existing expectations.

Description of changes

• Create a method in PDSQI-9 to resolve the instructions where 2 are replaced with instructions to return {explanation: str, grade: int}. Default behavior remains the published / vetted score-only instruction.
• Update the two Epic prompts to both use this dictionary response instead of a list, and to have a toggle to go between. But these will default to showing explanation.
• Update the eval scoring method to handle either dictionary response (instead of list) or direct value. This removes the argument to specify names for the subcolumns.

Author Checklist

• Linting passes; run early with pre-commit hook.
• Tests added for new code and issue being fixed.
• Added type annotations and full numpy-style docstrings for new methods.
• Draft your news fragment in new changelog/ISSUE.TYPE.rst files; see changelog/README.md.

[MiguelAFH]

Can we use score instead of grade?

[diehlbw]

Updated.

[MiguelAFH]

Also, just a general question. Is the python 3.10 requirement something that could be discussed to lower to 3.9? HELM uses python 3.9 so it conflicts with evaluation-instruments. This is also in my meeting agenda with the HELM team for tomorrow.

[diehlbw]

Also, just a general question. Is the python 3.10 requirement something that could be discussed to lower to 3.9? HELM uses python 3.9 so it conflicts with evaluation-instruments. This is also in my meeting agenda with the HELM team for tomorrow.

Can you write this up as an issue, it would not be done in this PR. And I'd like to get reasoning discoverable there.
My immediate thought are an unhelpful "maybe?" I can't think of anything offhand that uses 3.10 features, but two things for us:

• seismometer consistency: while the integration is currently lacking, the vision is to have them working together; seismometer is also 3.10 and much tougher to argue changing.
• python EOL: this will be most of the discussion, balancing the benefits of bumping this down to quickly come back and move it forward.

[MiguelAFH]

Also, just a general question. Is the python 3.10 requirement something that could be discussed to lower to 3.9? HELM uses python 3.9 so it conflicts with evaluation-instruments. This is also in my meeting agenda with the HELM team for tomorrow.

Can you write this up as an issue, it would not be done in this PR. And I'd like to get reasoning discoverable there. My immediate thought are an unhelpful "maybe?" I can't think of anything offhand that uses 3.10 features, but two things for us:

• seismometer consistency: while the integration is currently lacking, the vision is to have them working together; seismometer is also 3.10 and much tougher to argue changing.
• python EOL: this will be most of the discussion, balancing the benefits of bumping this down to quickly come back and move it forward.

After talking to the HELM team, this won't be necessary. HELM supports python 3.10 and 3.11.

[MiguelAFH]

I think it makes sense to use be consistent with how the enum is used and explained to the user. Here we set it to the string value but then the resolve_prompt function asks for one of the enum names, not the string values.

[diehlbw]

Changed everything to Enum