Spike: Update cloud FE's LaunchDarkly wrapper to handle arbitrary feature flags

[ambirdsall]

Right now, all the feature overrides we use are defined as variants of a single catchall feature flag, featureService.overwrites. Because LaunchDarkly user targeting (which we use to selectively release new features and for initial releases which can be "rolled back" with no deploy) is mutually exclusive (i.e. each user can only be assigned one single variant), independently toggling different features in parallel gets complex and fussy very quickly.

Instead, the frontend code which parses the LaunchDarkly dynamic flag assignments and provides flag values to application code should be able to find the values for new, independent feature flags with arbitrary names. For backwards compatibility, it must continue to properly query variants defined within the featureService.overwrites namespace until and unless all such feature assignments are deprecated.

[pmossman]

Refining notes:

• Main problem/pain point that this solves is that currently, all dynamic feature flag overrides in the front-end are scoped to a single "feature flag" in terms of LD's data structure. Within a single flag, assignments are mutually exclusive, so there's a ton of hassle around toggling multiple flags that will only get more painful as we add more and more flags.