add tests that verify behavior of generated code + generator errors/warnings

[eli-bl]

This creates two new categories of end-to-end tests that I'm calling "functional" tests:

1. Tests that run the generator against a valid spec (defined inline in the test code, specific to each test class, rather than in large spec files) and then import and execute pieces of the generated code. Unlike the "golden record"-based tests, these don't make assertions about the exact implementation of the generated code; they treat it as a black box and verify its behavior. These are in functional_tests/generated_code_execution.
2. Tests that run the generator against an invalid spec (again defined inline) and make assertions about its error/warning output. These are in functional_tests/generator_failure_cases. The reason I've put these in a separate directory is that they do not involve executing generated code; they're basically black-box tests of the generator.

I've added a bunch of tests in both categories, to cover generated model classes. There aren't currently any tests of endpoint behavior, but I think those could be pretty easily implemented using a mock HTTP client.

The intended benefits are:

• These tests prove that the generated code behaves as intended from the point of view of an application using the client. That's unlike the existing end-to-end tests (where we are verifying what the code looks like and only inferring what we think it will do), and the unit tests of the generator (where we're verifying the logic for the internal data structures that will be used to generate the code).
• They're more convenient for rapid development of a feature, as tests are lighter-weight and self-contained.
• They can replace many (most?) of the current low-level unit tests, which are too tightly coupled to internal implementation details and difficult to maintain.
• In case of a regression in the generator, failures in these tests can be more specific and easier to interpret. The "golden record"-based tests would also fail, but the output from those is often quite verbose and it can be hard to see which part of the diff is relevant, especially if the error is duplicated in many model/endpoint files.

This PR removes quite a few low-level unit tests that are now redundant; the coverage check in CI is proof that the relevant code paths are still covered.

I believe we could also greatly reduce the size of the "golden record"-based tests, and reduce those current very large specs to cover a smaller range of things, like the overall code structure of the generated client. I think it is safe to say that tests for things like "does a property with such-and-such schema get correctly translated into a model class attribute, with the right serialization/deserialization logic" would be better handled in the new functional test style. But I haven't removed any of those in this PR, since I think that's a bigger task.

[eli-bl]

I've rewritten this and other functions in this file to use the same generate_client context manager, even though the logic in the tests is fairly simple, for two reasons:

1. It enforces consistent state cleanup. Previously, failures in some of these tests would leave generated files behind in the project directory.
2. I think it makes the tests a bit easier to read by reducing boilerplate, so what's left is the logic specific to that test.

[eli-bl]

By the way, I think this mechanism would be especially useful for testing something like my discriminator PR, #1156 - since that is ultimately about validation behavior.

[eli-bl]

I know there's another PR extant for dropping 3.8, but I had to remove 3.8 from the testing matrix here because 3.8 has some differences in the typing module that would make some of the new test assertions a pain to implement.