Refactor location and address model for task, supplies, circles and users

[Ralf Schroeder]

We have a problematic implementation of addresses for our various key business objects which leads to complexity and bugs. Here is what we know:

1. We can track locations in the google style with geocode_query, longitude, latitude and the json for geocode_data. This information can help place spots on a map. For tasks and supplies, only locations are stored.
2. We can track precise postal addresses for circles and users. This is a structured object with fields such as street address 1, street address 2, city, state_province, postal_code, country. On this object, we also store a link to a location_id where we resolve the geo location.

Known issues:

• When we enter a partial query string in the location field (on page 'Find circle' and 'Add/Edit task' etc), we cause a new google lookup and store a new location upon each keystroke. This leads to many orphaned useless location entries.
• Tasks have a joiner table task_location_assignments which seems unnecessary. Supplies do not have that but join to location directly.
• Addresses store both address info AND a link to a location. This might be redundant.
• This issue includes #310

[Ralf Schroeder]

@mkristian Something to look at for cleanup...