Precommit mypy increment

[MattWellie]

Down to 119 mypy failures

[jmarshall]

I can't review this without explanations of why you're making the changes you're making. In particular:

• Replacing instances of cpg_utils's Path by (pathlib.Path, CloudPath) seems like a backwards step. What is the reason for it?

• Adding # type: ignore annotations should be an absolute last resort IMHO. What errors are being reported in these various instances, and why can we not reasonably refactor them away?

[MattWellie]

1. See Unexpected error behaviour: Parameterized generics cannot be used with class or instance checks python/mypy#12155, error: Parameterized generics cannot be used with class or instance checks - mypy (rightly or wrongly) doesn't support using our Path (a union of CloudPath | pathlib.Path) in isinstance checks
2. Most of the type: ignore statements are around Hail ResourceGroups - there's no way I can see to solve error: Value of type "Resource" is not indexable for named ResourceGroups, Hail does some job-creation-time magic to swap out job.output['vcf.gz'] for a filepath, and the entity job.[arbitrary_name] can't really have a fixed type.

Other instances of the latter are around expected_outputs - when returning a dict[str, str | Path], mypy fails with incompatible type on all usage of the contents unless the expected type of each is literally str | Path. We could pull out each value individually and assert a specific type, but... there's 120 more errors to address and only so many hours in the day.

[jmarshall]

As you say, there are a lot of such instances, and it would not make development any more fun if we have to annotate our new code similarly.

I think we should look at selectively disabling some type checking (e.g. perhaps saying that whatever returns the expect_outputs returns them as Any; or nixing this plan to expose cpg_utils to mypy) before carrying on down this road of putting ignore directives everywhere.