Future-proof metrics infrastructure

[BenHenning]

After a discussion with Sean today, it became clear that a number of changes would really help future-proof the maintainability of metrics logged in the app. Specifically:

• We should introduce a new proto enum to define all possible event IDs.
• We should introduce a property for all events that provides an integer-based ordinal of the event's proto enum property. This will act as a long-term, immutable ID that can be queried instead of the event_name property (so that we can change that later on without concern).
• A new proto & textproto should be introduced (along with parity tests) to map all event IDs to human-readable strings.
• Logging should be updated to use an event's human-readable string as its event_name instead of the current definitions.
• A separate textproto file should be introduced for the Kenya study that uses the old names for parity.
• A new flavor of the app should be introduced specifically for the Kenya study that also selects the separate textproto file in order to configure the events accordingly (using a Bazel select setup, probably).

[BenHenning]

Note that it's probably important to get this in for beta MR1 so that the first time we start receiving production metrics will be in a way suitable for long-term querying and aggregation (i.e. using the new, forward-compatible ordinal).

[BenHenning]

Note a couple of things:

1. The Kenya study-specific flavor is being introduced as part of Create Kenya study-specific build flavor & version codes #4410
2. I decided to go with a code approach to this to both simplify things (can use the existing oneof typecase enum rather than creating a new enum altogether) and so that Kotlin can enforce comprehension on the enum constants in case a new one is added