Consider renaming database and/or API fields for clarity

Some fields in the calevent and caldaily database tables can be a bit difficult to understand. Some examples:

• calevent.name is the organizer name, calevent.title is the event title; "name" can be misconstrued as "event name"
• calevent.locdetails instead of location_details
• calevent.time is implicitly start time, but calevent.endtime is explicitly end time
• caldaily.id is actually a foreign key pointing to calevent.id, and caldaily.pkid is the "true" id of the occurrence

MySQL allows columns to be up to 64 characters long, so we have some room if we want to make them longer for clarity.

Related, the events API output mainly mirrors the database column names, but doesn't strictly need to.

• The caldaily_id field surfaces the internal db name which is irrelevant to API consumers. We could probably make it something more meaningful like occurrence_id.
• Some fields aren't useful, e.g. hideemail. If hideemail = true then the backend ensures that email = null in the output; there shouldn't be anything for the API consumer to do. If hideemail = false then the email is provided and there's also nothing for the API consumer to do.
• Boolean fields like featured could possibly be renamed to is_featured to better match boolean conventions.

This is also generally true for the manage_event and retrieve_event endpoints, though we don't currently (and haven't historically) had any external consumers for those APIs. We should keep consistency between the endpoints where possible and beneficial, though.

Start by inventorying the calevent and caldaily database fields and the events, manage_event, and retrieve_event endpoint outputs described here. Before implementation, establish which names should change and how consistency will be maintained across database and API responses; done would require an agreed scope and coordinated updates.