Rework code generation, dependency management

[raddevon]

This was prompted by our guide being broken with a recent release of FastAPI. We want to use the default multi-file code generation option rather than the single-file option. We also want to install and test against the latest versions of all dependencies rather than trying to pin dependencies.

[raddevon]

OK, got into a fight with the CI tasks, but I think they're working now. 😅 That said, the testing that is in place would not have caught the issue that got us here. I'm getting these changes in first to give me time to get a video done by the end of the week. I'll have to circle back to the more in-depth testing that will be required to cover us in a case like that one as a separate PR. (The server would start but threw when I hit /users with a GET, but only when multiple users were being returned.)

A few notes:

• Server now runs on 5001 since later versions of macOS have an AirPlay server running on 5000 out-of-the-box. I went ahead and changed the port in the health check script too, even though it won't be required on CI, just so that script will also work under macOS without jumping through any hoops.
• make now handles creating the virtual environment so that what's happening in CI can mirror what we're asking of the user (and so that users can use make to bootstrap the example app)
• Not in love with having to use multiple types that are essentially the same. This is a downside to multi-file generation that makes the code less readable/understandable and really mangles the formatting of the return annotations IMO, particularly on get_events. I could assign all of the imported types to variables to make them shorter so the formatting is better on return annotations, but that's just moving the mess around.
• I kinda think this makes things a bit less readable even aside from that. For my money, it's harder to read get_events_async_edgeql.get_events(client) than db_queries.get_events(client). The former forces someone reading the code to have extra context — that we've generated code from queries and that a single module was generated per query, each containing a function that runs that query, hence the apparent redundancy — but I understand the desire to run the generator without any options as the user's first exposure to it. I'm just not sure it's a great trade-off.