This is the first part of the API. It supports most of contacts, as well as the
journal. This PR also brings Monica to Laravel 5.5, as the API required it with
the new concept of resources. It needs to run `php artisan migrate` as well as
`php artisan passport:keys` to generate the access tokens needed for the API.
* Edit relation docblocks of Contact model
* Move activities to its own controller
* Move reminders to its own controller
* Move tasks to its own controller
* Refactor Gift in preparation for the move
* Move gifts into its own controller
* Fix failing tests
* Move debt to its own controllelr
* Fix tests failing on PHP7
* Move significant others to its own controller
* Move kids to its own controller
* Move notes to its own controller
* Some more adjustments & solving #277
And more query optimizations
Fix#127 and #94
* The gifts are now using the same tables at most of the other data sets of the page.
* Show who the gift is for
* Show comment if defined for a gift
This is just causing too much headache, especially since I made the rookie mistake of not checking the max length of some entries when inserting the gift. That leads to errors in the decryption process.
In production, out of the thousands of gifts already entered, only 5 are not decryptable. I have no other choice than resetting these 5 rows. I'm really sorry about this.
If you do end up having problems running the migration in your own instance, you need to remove the rows that are un-decryptable in the Gifts table as well.
This normalizes all relationships and adds relations to models to take advantage of laravel's eagerloading and reduce queries to the database.
This might go against the 'add any kind of complexities whatsoever' rule in the contribution guide, but I think adding relations would eventually simplify the code base. The amount of queries just on the dashboard fell from ~70 to 26. There's also a lot of boilerplate code in the Contact model to retrieve relationships and to maintain accurate count of them (fields like number_of_*). They can be greatly simplified with the addition of relations.
One other thing in the Contact model was the definition of the Contact-User relation. This definition uses the account_id field in the contacts table and and relates it to id in users. I'm not sure if this is the intention, since the id from accounts table is used when assigning account_id for a contact. This seems to have worked so far, because both a user and its associated account are created at the same time during registration and their ids match, but if there was any difference, this relationship would relate wrong contacts and users. I changed the relationship name to account. This makes the path to a user from a contact is $contact->account->user right now.
