fix: Store configuration atomically

[typotter]

🎟️ Fixes FF-4302

Motivation and Context

The PHP SDK stores flag, bandit, bandit reference and config metadata in separate entries in the cache. This design: the reliance on metadata to determine whether to repopulate the cached config entries is susceptible to the volatile nature of the cache. Entries are evicted and go unfound when assignments are attempted until the cache expires.

Description

• This change heavily relies on the ConfigurationWire format. Added classes define the ConfigurationWire format and its sub-types.
• New traits to assist with converting to/from JSON associative arrays (aka dicts)
• singular Configuration object - holds the flags, bandits, references and metadata
• ConfigurationStore - refactored to hold the current, active configuration and load configuration from the persistent cache when needed
• Ditched UFCParser and moved the logic to Flag
• ConfigurationLoader deals just with checking the expiration of the cache and handing the eTag off to the Http client.
• reloadIfExpired removed from assignment calls. PHP processes are short lived. The process starts up, the EppoClient is initialized, a response is computed and sent to the client, then the process dies. Configuration is loaded from the cache on each init, and if expired, the config is fetched from the API
• Modified EppoClient to pull the current config object once for each assignment operation and use it through the operation.

How has this been documented?

External API is unchanged. Behaviour is fixed.

How has this been tested?

• existing suite of tests
• additional tests

[aarsilv]

Nice work rewiring all this! Much cleaner and easier to understand. And now we know the configuration will be atomically in sync too 📈