Reworking database model

As outlined in #82.

This isn't currently 100% - I'd prefer the reviews model gets merged in first because I'm sure I'll have to do some manual merging to get everything working.

However, this is substantially complete.  Of note:
- There's now one address field.  The `db_fun` stuff, when executed directly by the scrapers, will look for an `address` field on the provided rad_record and use that if it's provided.  If not, it will try to manually construct an address based on the different available segments (`street`, `city`, `state`, `zipcode`, `country`) and use that.
- The `visable` column on the Resource model was successfully renamed.
- I also added a `visible` column to the Category model.
- There's a new event handler in `models.py` that listens to `before_insert` and `before_update` events on each resource.  When this is triggered, it will turn the names of the selected categories into a comma-separated list and store that as the `category_text` field.  The text search functionality now supports filtering on this field.  Moreover, this handler detects when a URL that does not start with `http://` or `https://` has been provided, and will normalize it to start with `http://`.
- The provider template was updated to handle all the new fields - it also is a little smarter about which areas should be displayed, depending on which values have been provided.

There's also now a [wiki page](https://github.com/radremedy/radremedy/wiki/Database-Schema) for the schema so far.
I wanted to support either format - if an import has just an "address" field, that's fine, but if an import has separate address fields, the system can handle that as well.