Clean up EIA-861 table and column names

[zaneselvans]

In #3283 we found a number of EIA-861 tables with not particularly informative names, leftover from our initial integration of the dataset which we had thought was "interim" but has now been in some form of usage for almost 4 years. Some proposed renames:

Tables to Rename

Note: these are just ideas that came up in review of #3283 and aren't meant to be comprehensive or final. We should talk about whether these names make sense / are consistent with other names and do a more complete review of the bajillion columns in the EIA-861 that we never fully cleaned up.

Old Name	New Name	Notes
core_eia861__yearly_demand_response	``
core_eia861__yearly_distributed_generation_misc	core_eia861__yearly_distributed_generation_capacity	ref
core_eia861__yearly_operational_data_misc	core_eia861__yearly_energy_sources_dispositions	ref
core_eia861__yearly_operational_data_revenue	out_eia861__yearly_operating_revenues	ref
core_eia861__yearly_utility_data_misc	core_eia861__yearly_utility_activities	ref
core_eia861__yearly_utility_data_nerc	core_eia861__yearly_utility_nerc_regions	ref
core_eia861__yearly_utility_data_rto	core_eia861__yearly_utility_rtos	ref
core_eia861__yearly_demand_side_management_ee_dr	EE & DR are cryptic	ref
core_eia861__yearly_energy_efficiency	core_eia861__yearly_energy_efficiency_programs	ref
core_eia861__yearly_reliability	core_eia861__yearly_reliability_metrics	ref

Columns to Rename

Old Name	Suggested new Name	Notes
advanced_metering_infrastructure	advanced_meters
alternative_fuel_vehicle_activity	alternative_fuel_vehicle_activity_current_year
alternative_fuel_vehicle_2_activity	alternative_fuel_vehicle_activity_next_year
annual_total_cost	annual_total_dsm_cost
automated_meter_reading	automated_meters
caidi_w_major_event_days_minutes	caidi_with_major_event_days_minutes
caidi_w_major_event_days_minus_loss_of_service_minutes	caidi_with_major_event_days_minus_loss_of_service_minutes
caidi_wo_major_event_days_minutes	caidi_without_major_event_days_minutes
generators_num_less_1_mw	generators_less_1_mw_num	Convention for numbers of things?
generators_number	generators_num	Convention for numbers of things?
green_pricing_revenue	green_pricing_revenues	We have many revenue(s) columns. Standardize?
incremental_life_cycle_peak_reduction_mwh	incremental_life_cycle_peak_reduction_mw	Units Error??
major_program_changes	major_dsm_program_changes
merge_address	merger_address	Several of these merge fields.
net_power_exchanged_mwh	net_energy_exchanged_mwh	Weird to say "power" but mean "energy"
net_wheeled_power_mwh	net_wheeled_energy_mwh	See above.
non_amr_ami	non_amr_ami_meters	Indicate it's a number of meters?
plant_type	???	Needs resource specific description / constraint.
rec_revenue	rec_sales_revenues	to match rec_sales_mwh?
revenue	``	too generic.
service_type	electricity_service_type	too generic?
standard	electricity_reliability_standard	too generic?
utc_datetime	datetime_utc	standardize on an ordering.
utility_owned_capacity_mw	`utility_owned_non_net_metered_capacity_mw

Other notes:

• Lots of the reliability data (SAIDI/SAIFI) have very long names that can maybe be simplified but stay clear?
• There's a more generic data modeling issue showing up here, which is that we often have very generic column names which do make decent sense so long as they're in the context of their home table, but outside of that context they'll be mysterious, and they could easily appear in more than one table inadvertently with somewhat different meanings and not be described independently. To what extent do we intend for column names to stand alone? How unique should they be? How much context should we assume the table they are in will provide?