I think this could be how we generate other lists
Problems:
- Knowing it's a location is good because you can do nice stuff on the
frontend.
- Same for contacts & events.
So a good alternative, is to still use this type, but perhaps change the
database such that all lists live within the new tables (lists,
image_lists). But have special tags.
This would also make it easier on the AI I think.
This allows a single table to be used to process images, meaning if
anything happens to the system we can always return to polling the
database and process these images individually.
Because of this we also want an `image` table to contain the actual
binary data for the image, so we aren't selecting and writing it each
time, as it is potentially a bottleneck.