Update API and Admin interface to support fields defined in the OpenReferral spec.

[monfresh]

This should really only be done once version 1.0 of the spec is released, which is currently scheduled for January 5, 2015. However, I have started pulling in some fields that I think are not likely to change. You can follow the progress in this PR: https://github.com/codeforamerica/ohana-api/pull/235

The spec is currently at v0.2, and if there are any changes between v0.2 and 1.0, they will not be incorporated in the API until v1.0 because it does not make sense to keep changing the API while the spec hasn't been finalized.

[monfresh]

This is about halfway done now, and PR #235 has been merged into master. The remaining tables that need to be updated are:

• [x] Services
• [x] Programs
• [x] Regular Schedules
• [x] Holiday Schedules

The Metadata table will not be supported as it is currently out of scope. We tried to implement such a change tracker, but realized it was a lot more complicated than we originally thought. See PR #191 for more details.

[monfresh]

Programs have been added today. The schedules tables are the only ones remaining, but note that the API still supports the text-based hours field. My guess is that most of the people who will be importing data into the API have hours of operation listed as a String in one flat field. That means that the API technically supports all the fields from HSDS now.

[monfresh]

Regular Schedules are now available.

[monfresh]

Holiday Schedules can now be imported into the DB. Admin interface support following shortly.

[monfresh]

This is now complete, based on the tables and fields from version 0.4 of the spec that are not still under discussion. The following fields, tables and relationships are still being discussed and therefore are not present in the API:

• The SMS field in the Services table will most likely end up as a number_type in the Phones table. Once the spec makes that change, the API will be updated. (The SMS field is not currently in the API).
• The language_line field will most likely be renamed to translation_service or interpretation_service and will be a freeform text field as opposed to only accepting a list of language codes. (The language_line field is not currently in the API).
• The Eligibility table needs to be refined in the spec to define specific fields, such as min_age, max_age, max_income, gender, and other attributes one might want to search on. Currently, the API has a text field called eligibility in the Services table. Once the spec is updated, a new Eligibility table will be created with the appropriate fields.
• The logical model in the spec allows for Services to belong to an Organization, but that will not be allowed in the API. All Services must belong to a Location so that they can be searched. The spec must remove that relationship.

[monfresh]

Completed with #309 and #310.