Sqla-raw

Being devoted to reducing boilerplate and convention-over-configuration as design aims, `sqla-raw` handles all Engine and connection setup by default, requiring only a `$DATABASE_URL` in the environment to begin submitting queries and getting results. That hasn't changed, but with this release it is possible to instantiate an Engine explicitly using `db.engine()`, in case you need to use multiple databases, or want to set other Engine parameters to non-default values, for example to change the `pool_size` or set `echo=True` to have it log the submitted SQL statements. Usage details in the [README](https://github.com/nerium-data/sqla-raw#sqlalchemy-engine-invocation).

Hey hey, it's finally the official 1.0 release! Hopefully all the features and options are described in the README, but to try to summarize recent changes that got us to this point:

- SQL may be submitted as a string, by a path to a file containing SQL, or by file name using an automatic path-lookup convention
- Results returned as list of dictionaries by default. May optionally return a list of tuples, or a SQLA `ResultProxy` object instead
- Instantiates a single SQLA `Engine` instance per program run
- Complete set of unit tests
- Expanded README with fuller usage notes

Add `result_by_name()` method

Takes a file stem name, searches for it in a local directory (at `QUERY_PATH` or `${PWD}/query_files by default), and hands off to `result()`

Add `returns` arg to db.results() method
- can specify results as tuples or sqla ResultProxy object (see README for usage details)

Other changes:
- append application_name to DATABASE_URL
- add tests to get coverage up to 100%
- expand and revise README

Instead of catching database operational exceptions and returning them in a dictionary, which was the original behavior, — as of this release, database errors are simply raised as they would be if using SQLAlchemy or a DB-API driver directly. Logging exceptions was also considered as an alternative to raising them, but this decision to let them happen seems better and I have noticed it is in keeping with prior art in this area, such as Records or PugSQL.

The original behavior was included due to my concern that database errors can be hard to test for, and might occur due to missing or erroneous user behavior rather than due to software bugs. It might well be a bad idea, from the point of view of an application that uses this library, for execution to halt on such errors. Where that is the case, it now seems to me better for any code that calls `db.result()` to wrap that call in a try/except block, than for the library to attempt to anticipate this and catch the error itself.

Obviously, this could be a breaking change (I imagine it will be for Nerium) and any consumers should test their applications carefully when attempting to upgrade.

Adds `db.result_from_file()` method, which takes a path instead of a SQL string and reads the SQL from the file at path.