Unify the "default" label options

[Abby-Wheelis]

In unifying the base mode colors #143, we've encountered the fact that the "default" label options are stored in a few different places.

em-common seems like a good place to keep them, so that the phone and dashboard can both rely on the same dependency. While we're making this change, we can also remove the old csv files, and remove the example json files from nrel-openpath-deploy-configs to keep the defaults all in one place.

The basic goal we need to reach is:

I agree with Jack that there should really be: (i) platform specified modes and (ii) user specified modes. I am willing to have: (i) platform specified default modes, (ii) platform specified custom modes, and (iii) user specified modes.

We already handle "(ii) platform specified custom modes" - that is what our dynamic labels are
We need to centralize "(i) platform specified default modes" - it is seeming that the best way to do this will be to rely on a central file in emcommon label-options.default.json instead of the csvs we currently use. We can also use this as the basis for the examples that we show deployers, and remove the other example files from nrel-openpath-deploy-configs.

Currently, (iii) user specified modes get displayed on the dashboard as "Other"

[JGreenlee]

Agreed. I will also remove label-options.json.sample from e-mission-phone when it is ready to use label-options.default.json from emcommon.

Speaking of cleaning up label options, we need a strategy to migrate the the label options of active deployments.
https://github.com/e-mission/nrel-openpath-deploy-configs/tree/main/label_options
There are only a few that have their own label options (looks like caebike, godcgo, and usaid-laos-ev)

kgCo2PerKm will not be used anymore. Since each label option already has a base mode, and base modes have their own footprint data now, those will be inherited. So for the most part, it should just work
But if there are any label options that had a custom kgCo2PerKm value and the base mode's footprint is not adequate, we need to add a footprint to override the base mode's footprint

For example I think that at least with caebike, we need to come up with footprint values for bike_scooter_share and bus_train, because the base modes for those are BICYCLING and BUS, not accounting for scootershare or train

kgCo2PerKm can stay in all configs for backwards compatibility. After a few releases, we can remove kgCo2PerKm, rename baseMode -> base_mode, and remove the redundant declarations of met / met_equivalent (in cases where the same value is already being inherited from the base mode)

[shankari]

@JGreenlee wrt

After a few releases, we can remove kgCo2PerKm ...

we may want to change the dynamic config download to be auto instead of manual so that people in those programs will have the new config, even if the program is long-running.

Ideally, we would have the auto vs. manual be a config option itself, to also support other community-based apps that want to ensure that surveys are not changed in the middle of the data collection, but I would suggest that should be an option in config.xml (at the app level) so that we don't have the "auto-update config" flag be part of the config. In which case, we should deal with it as part of #850 (comment)