Create locations table

[PhantomWatson]

• [ ] Create a locations table with name and address fields
• [ ] Use this table for auto-completing location names
• [ ] Use this table when auto-completing addresses for known locations

Arguments for alternate ways to handle fields in events table

Keep location field

• Less code needs to be changed

Remove location field

• Searching for events at a given location by using location <-> event associations might be faster than searching by matching strings in location field
• It would be easier to mass-edit location names if a venue changes its name (but should old events still use the then-current name of that venue?)

Keep address field

• Less code needs to be changed in the site and the API
• Variations for addresses are allowed, in case there's ever a "suite B" edge case
• Removing the events.address field would mean that either
  • the address can only be inputted when an unrecognized (new) location is being used and is otherwise displayed but disabled (which would be complicated and may confuse users)
  • the address input field is always enabled, allowing any user to update the location's address (potentially wreaking havoc)
  • the address input field is always enabled, but a complicated system of moderating address update suggestions is implemented (doesn't seem to be worth going to all of this trouble)

Remove address field

• Addresses for location names (pulled from $event->location->address) are all uniform and can be more efficiently corrected