ActiveRecord up in here!

This is a big PR. It requires [this G5Hub PR](https://github.com/G5/g5-hub/pull/53) to be merged and deployed or it will explode. Because that PR makes a change that might affect the CPNS/CPAS, I may have created a circular PR dependency. Whatever.

## Big Ticket Items
1. `G5Updatable::Client` and `G5Updatable::Location` are in the engine. If you have a related model like the CPNS has, your model should drop everything but a `location_uid` field and be named something different that describes what it now stores. In that case it is now `ContactInfo` or something.
1. Your microformats2 parsing stuff and the Virtus models are ripped out. Matt and I built a gem called `g5_foundation_client` that did much the same stuff, so I guess great minds think alike. We didn't have a concept of clients yet, so I improved our gem and made you use that. The gem might come in handy some day for apps that don't need a full location/client database but do have a UID and want a working Virtus model.
1. To make it so we don't have to run the same migration on a thousand different apps when the G5Hub schema changes, everything but the `uid` and `urn` are stored in a `json` datatype `properties` column on those two models. There's some magic around letting people still call `client.name`. I can see a case for making some attributes into first-class columns for querying purposes, but we'll cross that bridge when we get there. Because it's `json` and not `hstore`, values of simple datatypes like booleans and numbers will come through properly, but more complicated ones like dates will not. I just didn't want every single column from the G5 Hub to have to be represented on every app for every client. It would get ridiculous fast.
1. The configuration stuff is gone. The need for updating specific models or attributes is gone now. I've changed the endpoint to receive a `client_uid` parameter instead of a `urn`, which makes another configurable value useless. The only one left that you can use is setting the `client_uid` of each app, but that is never going to be in a configuration file somewhere, it will always need to be set in an environment variable. So I ripped that bit out.

## Minor Stuff
1. The Fabricators are gone. It's a long story, but this app needs the Virtus model factories that `g5_foundation_client` provides, and those are FactoryGirl. I used the same technique in this app as I did in `g5_foundation_client` for providing factory definitions to implementing apps, but again it is using FactoryGirl. I'm sure there's a way to do it for Fabricators too, I just didn't do it. I'll get this working in my apps that use FactoryGirl and we can tackle the other one when this branch gets put on those other apps. If those apps factory setups aren't extensive, then we can just switch them.
2. There are new rspec 3 deprecation warnings for some stub methods that `g5_foundation_client` adds. I can't switch to the new syntax on the gem until CXM/CLS are upgraded to 3. Deal with it.
3. Some of the attribute names in `g5_foundation_client` (which then end up in the ActiveRecord models) do not match what you had on the original Virtus models. This might affect you when you migrate CPNS/CPAS, but not too badly.

###### Location
  * `phone_number` -> `phone` I did this because the CPNS wasn't actually using that attribute, and `phone` is what we chose in the CLS.
  *  `state` -> `region` We have to think of the Canadians.
  * `city` -> `locality`

###### Client
  * `type` -> `domain_type`

I'm going to be installing this branch onto CLS and using it to iron out any bugs or missing features. I think we can deploy the G5Hub changes without breaking the CPAS/CPNS, and I can help you with migrating those two when the time comes. It should be just a little bit of database table shuffling and some manual setting of a few attributes and that's about it.