Add documentation for current and ideal design to gtfs-lib README

[landonreed]

Over the past couple of years, there have been two code paths with sustained usage for loading and validating GTFS feeds: one backed with storage in a relational database (specifically PostgreSQL) and one for use with MapDB. The intention was to have a generic interface for load/validate commands that could use the same validation checks on data retrieved from either storage system, but this goal was never reached. As a result, different validation code is used for both and the generic load interface only supports the relational database-backed system, which is used by the Data Tools application.

In anticipation of decreased ability to collaborate on this library (although we expect sustained usage in its different parts), we need to document the current use cases this library supports and both the actual and intended design more fully.

[abyrd]

Copying some discussion over from a Slack channel. We should record this thinking about why we're not using an ORM: "you could just do some straight SQL and read the fields via the JDBC API. If you need to manipulate the objects extensively within a Java environment, so you want to map the response rows into objects, you'll need something like the EntityPopulator used for other entity types. As Evan says an ORM is a general purpose solution for that case; the main reasons we are not using one are a) bulk-loading speed, b) the need to represent and preserve tables with extra fields that are not present on our internal/standard GTFS model objects, c) the desire to preserve as much erroneous / incorrectly typed data as possible during validation and reporting."