Store claim in db

### This pull request does a number of things

### ...Introduces a `Claim` class for storing claims in the database.
- A claim only exists once a claimant's personal details can be matched to some employee details
- Claims are currently made of two hstores and an id and get surfaced to the rest of the application as a tuple of dicts: `(claimant_information_dict, employee_records_dict)`.
- The ids are currently auto incrementing... in real life we should probably use guids.
- There is a highly [sophisticated serialisation process](https://github.com/InsolvencyService/rps-alpha/commit/d0a6d5d9a723455fc944215495fdaefde0bc39e3#diff-65db00b525e9f8cd6e5a77a69c2c5dbcR18) for dealing with non-string types

### ...Separates mapping claimant details to employee records and finding discrepancies
- The claim object stores claimant details and employee records
- The `comparable_values` method works out if the values match to each other (currently we only have one set of matching values)
- The `find_discrepancies` method returns a list of discrepancies. It takes a claim_id and is the only discrepancy code the front end should care about

### ...Makes the `claim_service` deal with three things
- Creating new claims
- Updating existing claims (via the claim_id)
- Spitting out discrepancies (also via the claim_id)
- The thinking being that it's better for the frontend to tell the rest of the application to deal with claims rather than ask for them back and mutate them in the controllers.