Use Sequence instead of list in compose[_to_dict]

[maddenp-cu]

Synopsis

I've run into a typing issue a couple of times now, most recently in AIGFS work, that looks something like this:

demo.py

from uwtools.api.config import compose_to_dict

configs = ["a.yaml", "b.yaml"]
composed = compose_to_dict(configs)
print(composed)

$ make typecheck
make[1]: Entering directory '/home/maddenp/git/uwtools'
recipe/run_test.sh typecheck
=> Running typechecker
+ mypy .
uwtools/demo.py:4: error: Argument 1 to "compose_to_dict" has incompatible type "list[str]"; expected "list[str | Path]"  [arg-type]
    composed = compose_to_dict(configs)
                               ^~~~~~~
uwtools/demo.py:4: note: "list" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
uwtools/demo.py:4: note: Consider using "Sequence" instead, which is covariant
Found 1 error in 1 file (checked 176 source files)
make[1]: *** [Makefile:50: typecheck] Error 1
make[1]: Leaving directory '/home/maddenp/git/uwtools'

Here, mypy infers the type of configs to be list[str]. Fair enough. But a list is mutable, and type type on the other side of the call is list[str | Path], which means that the called code could e.g.

configs.append(Path("c.yaml"))

But the calling code believes that all the items in its list are str objects, so that it could be able to e.g.

[x.swapcase() for x in configs]

But Path does not have a .swapcase. So mypy flags this as an error.

The Sequence type doesn't claim to support mutating operations (e.g. .append), so typing configs: Sequence[str | Path] is a promise to not mutate configs, while solves the issue mypy is flagging.

In short, this makes the compose and compose_to_dict functions friendlier to users by making it less likely for typechecking they might perform to flag a (probably non-existent) issue.

Type

• Code maintenance (refactoring, etc. without behavior change)

Impact

• This is a non-breaking change (existing functionality continues to work as expected)

Checklist

• I have added myself and any co-authors to the PR's Assignees list.
• I have reviewed the documentation and have made any updates necessitated by this change.
• Where helpful, I have written comments in this PR's Files changed view to assist reviewers.