Typecheck with mypy

[dkfellows]

This is an adoption of #694 as a project-internal internal PR.

• [x] Types check
• [x] Unit tests pass
• [x] Integration tests pass

---

Tricky points:

• Various bits have to come from typing_extensions to work in 3.8; by 3.12 they're in Python itself.
• Pretty much every file requires from __future__ import annotations as the first line, which causes all annotations to be left as uninterpreted strings. (Without that, the syntax for unions would need to be much more wordy and things are bad enough as it is...)
• Type aliases usually need to be Foo: TypeAlias = "Bar | Grill" so that they get handled right.
• The new type declaration syntax of 3.12 isn't supported at all.
• Great care needs to be taken when doing specialization of a generic superclass in a subclass or using cast or isinstance; the type isn't auto-stringified there.
• Dataclasses require care:
  • Class variables must be annotated as such with ClassVar
  • You need to @hydrate the class before it is processed by @dataclass to make class variables be handled right.
  • The type of ordinary variables is sometimes stricter than the arguments that would be accepted. Handling the case where one narrows types (e.g., converting strings to enum members) during construction is not handled well by dataclasses; I ought to chase that up more generally...
• I've started to tame the wild dictionaries with TypedDicts, but that job isn't complete and I've no idea how much effort should be put into it; this has been one of the slowest parts: identifying where types could be narrowed.
• Dictionaries that come from JSON should more likely be dict[str, Any] than straight Dict; JSON doesn't allow non-string keys.
• Imports guarded by typing.TYPE_CHECKING have no constraints based on name resolution order... but can only be used in uninterpreted types (as the code isn't actually executed by Python).

[dkfellows]

I've been investigating a bug, when handling the EAR end step workflow callback (i.e., not in the main script itself), parameters would not have their value class set when processing the results. I'm not at all sure why this would be so (as the schema had been parsed and the parameter class modules loaded) but it was resulting in the reading out of values from an HDF5 file not working. I've resolved it by doing the forcing at that point (because the alternative is a definite failure! New method Parameter._force_value_class()) but it's really odd because I can't see why the parameters are wrong in the first place.

[dkfellows]

Do #699 first; it will be easier that way round.

[dkfellows]

This looks pretty good to me now. I'd love the documentation of the typed dictionaries to be better... but I'm not fixing Python itself so it will just have to be what it is.

[dkfellows]

These are bizarre failures, FWIW. I can only reproduce them locally by not having Python on the path.

[EDIT] And they seem to be transient. Probably container-related. Oh well.