Voter-tools

In the last ~24 hours, the PA sandbox API started sending undocumented error codes for some of our test cases. They... don't really make a lot of sense, but they're _similar_ to the documented codes. This update adds some leniency in what we accept in PA API responses. It won't be perfect; I'm hoping the fine folks in Harrisburg can fix this one quickly.

Add a new `UnparsableResponseError` for cases where the Pennsylvania API returns genuinely indecipherable content (invalid JSON, XML, or data not conforming to their own defined schema.)

Add a `raise_validation_error` kwarg to `set_application()`, defaulting to `True`, that raises an `APIValidationError` when the Pennsylvania API returns one. If `raise_validation_error` is set to `False`, the returned `api_result` may have `has_error()` set to `True`; otherwise, it won't!

Including a number of tests that mock responses from the PA API based on actual responses I've encountered in practice.

Error handling feels pretty buttoned up at this point.

Our client code had a couple different error-handling approaches. Unfortunately, the Pennsylvania API itself _also_ has multiple approaches.

With this update, we simplify the outward exposure of Pennsylvania API errors as follows:

- All errors raised from `voter_tools.pa.client.*` derive from `voter_tools.APIError`.
- Some of those indicate special cases, like `InvalidAccessKeyError`, `ServiceUnavailableError`, and `TimeoutError`.
- One of those indicates bugs in the library itself (`ProgrammingError`) and should never be observed in practice once this library is mature/complete.
- The remaining and most important error type, `APIValidationError`, indicates that the API rejected a voter application request due to a validation error. It provides structured errors and an API _similar_ (but not exactly identical to) Pydantic's `ValidationError.errors()` and `.json()` methods.

I think we've got it now.