Sqla-raw

This release is compatible with and tested against latest SQLAlchemy 2.x release. Also tested locally against 1.4.54 and tests appear to pass, so there's no minimum version pin for SQLAlchemy in case run alongside another package that pins it down.

Also removing support for query_path on S3. The implementation was ugly, it added a LOT of secondary dependencies, and I don't think anyone was really using it.

Finally, merged a PR that prevents `sqla-raw` from appending `application_name` to database connection URL in case it's run against Oracle database, as Oracle apparently neither supports this query string parameter nor quietly ignores it.

At the moment, row handling in `sqla-raw` is not compatible with API changes in SQLAlchemy 2.x, resulting in errors on converting results to dictionaries or tuples. While we work on the transition to latest SQLA, this release pins to SQLAlchemy legacy.

With this version `sqla-raw` adds support for reading SQL query files from an S3 bucket, using the `s3fs` library

- `result_from_file()` can take a `s3://` URL to a specific file
- `result_by_name()` will glob through a bucket instead of a local directory if `$QUERY_PATH` in environment is a S3 bucket URL beginning with the `s3://` scheme

S3 authentication handled via boto environment variables. This usage is also described in the README.md

Local file methods continue to function in a backwards-compatible manner

Passing `autocommit=True` to `db.result()` (or related convenience file methods) will add that execution option to the `conn.execute()` call on the SQL text.

In its simplest configuration, `sqla-raw` gets a `$DATABASE_URL` from the local execution environment, and uses that as default connection string. In previous versions, the call to `os.getenv()` included in-memory SQLite database (`sqlite:///`) as a fallback default, in case the environment variable was not defined. This seemed handy and made some testing scenarios easier to provision, but could lead to confusing error messages in practice: an operator who hadn't realized that `$DATABASE_URL` was set to an expected `postgresql://...` value might be quite surprised to get SQLite syntax error exceptions when submitting SQL that's valid for Postgres but not supported in SQLite -- especially in the context of a larger program using `sqla-raw` as a library.

Better to have no default, and raise an exception specifically complaining that no database URL was specified when that's the case. That's the implementation from this release forward.

Calling this a minor update since the SQLite default was undocumented, it doesn't change the existing API meaningfully, and I doubt anyone is currently using it in a way that relies on the old default behavior.

Fixes a bug where appending APPLICATION_NAME to the database URL was breaking if the configured URL already had a query string in it