feat(flags): Include version and other feature flag details in /decide response

[haacked]

Feature request

Right now, it can be difficult for users to understand why a flag evaluated the way it did. It's especially difficult because a flag may have changed since the $feature_flag_called event. Anything we can do to provide more information is helpful.

I'd like to include the $flag_version in the $feature_flag_called event. To do this, we need to add more information in the /decide response.

Describe the solution you'd like

Today, feature flag information is in two different top-level properties of the /decide response body.

{
  ...
  "featureFlags" : {
    "hogtied_got_character" : "danaerys",
    "hogtied-homepage-user" : true,
    "hogtied-homepage-bonanza" : true
  },
  ...
 "featureFlagPayloads" : {
    "hogtied_got_character" : "{\"role\": \"khaleesi\"}",
    "hogtied-homepage-user" : "{\"is_cool\": true}"
  }
}

I propose we add a new section named featureFlagDetails:

"featureFlagDetails" : {
    "hogtied_got_character" : {
        "enabled": true,
        "variant": "danaerys",
        "metadata": {
            "version": 42
            "description": "The character path the user will take",
            "payload": "{\"role\": \"khaleesi\"}"
         }
     },
    ...
  },

You'll notice that information in featureFlags and featureFlagPayloads is repeated there. This is for a few reasons.

I modeled this new dictionary after the OpenFeature API. I'm not by any means suggesting we adopt it 100% right now. But no harm in moving to a format that OpenFeature clients will have an easier time with.

Second, our clients that understand this new format will have an easier time parsing this format and getting the info they need.

For example, down the road, we could add a posthog.getFeatureFlagDetail(...) method to each client that just grabs a node from this new /decide response. This can reduce the requests that server-side clients need to make compared to calling getFeatureFlag and then getFeatureFlagPayload.

Lastly, this format is scalable for new changes. For example, when we want to add a reason for a flag evaluation, we don't need to add a top-level featureFlagReasons property to the JSON.

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

[haacked]

In keeping with OpenFeature, I may name the top-level property flags instead of featureFlagDetails.