[FEATURE] Specify and clarify configuration parsing for flag configurations

[aepfli]

Requirements

How we are parsing and handling flags is different from implementation to implementation. Simply based on the fact how we grew as a project and that a lot of implementations have been done by multiple contributors. Now it is the time to rethink our parsing and handling of the configurations, especially for in-process.

Goals

• utilize schema validation as much as possible, instead of custom logic, on a flag and not on a configuration level
• define which file formats are supported (relates too [BUG] [File Provider] Support File Formats #1689)
• define what can cause a PARSE_ERROR: currently only an invalid targeting rule can cause this error, other schema invalidation result in a FLAG_NOT_FOUND
• define this in a way that we can test this via our testbed/test-harness

issue relating to this

• [BUG] Inconsistency in file provider and json parsing for different languages #1627
• [BUG] [File Provider] Support File Formats #1689
• [FEATURE] provider option to reject flag set with invalid rules #1487
• [BUG] Inconsistent error codes for edge cases #1679

[aepfli]

should we again create an ADR for this? or just do it?

[aepfli]

this pr is on hold due to this foundings open-feature/python-sdk-contrib#282