close #75

this became much bigger than planned, but it reflects a few aspirations for what a service-like application should probably look like

• FastAPI api.py module, including a /service_info endpoint conforming to the GA4GH spec. I didn't bother implementing updatedAt (it's optional) because I think it'd be kind of a hassle to update a datetime object every time we make a release. Maybe there's a way to automate this but not a priority IMO.
• An API tests module with reasonable coverage
• A library config module. I don't think we have any services right now that quite map to the dev/test/staging/prod schema (I took this from rails), but some are pretty close and we could tweak as needed. The idea here is that it's a central source of truth about what kind of an environment the app is running in, and then other modules (like a database module or the main API views module) refer to it when making environment-based decisions. The individual settings here (test and debug) are sort of general/predictive of what we might need in a given app. Lots of examples online also set a DB URL or DB connection configs here as well. (I also looked at pydantic-settings for this but I think it's a lot more than we need. )
• A logging setup module. This would also be shared with a CLI module (which is my next project for this repo).
• Add FAST rules from ruff. This depends on the Ruff update PR.

The service info spec lets you add your own additional fields if desired. For DGIdb, Adam added a "data version" field, for example. There's probably things we could do there for many of our APIs.