[ADR] Create ADR to Address Handling of Duplicate Flagset IDs Across Multiple Sources in `flagd`

[aepfli]

Context:
As outlined in #1809, flagd currently does not handle scenarios where the same flagset ID is defined across multiple sources. This unimplemented state results in a lack of synchronization or reconciliation between sources, which can lead to confusion or unpredictable behavior for users. While the documentation will be updated to clarify this limitation, a long-term solution is needed to address this gap in functionality.

Goal:
The goal of this issue is to create an Architectural Decision Record (ADR) to explore and define a solution for supporting better handling of cases where multiple sources define the same flagset ID.

Scope of the ADR

The ADR should address the following:

1. Problem Definition:
   Clearly define the problem, referencing [DOC] Remove outdated Resync Event section for Sync sources #1809 for context.
2. Analysis of Options:
   Explore potential approaches to handle scenarios where multiple sources define the same flagset ID. This could include:
   • Defining a clear priority mechanism for flag sources.
   • Supporting resync events in cases of flag deletion.
   • Introducing conflict detection and resolution mechanisms.
   • Explicitly rejecting configurations with duplicate flagset IDs at startup or runtime.
   • Evaluate if we violated https://github.com/open-feature/flagd/blob/main/docs/architecture-decisions/duplicate-flag-keys.md?plain=1#L25 as the behavior has changed, and if we need to do more than just prepare the adr.
3. Trade-offs:
   Evaluate the trade-offs for each option, including complexity, performance impact, and user experience.
4. Proposed Solution:
   Recommend the most viable approach and outline the steps for implementation.
5. Future Considerations:
   Identify potential extensions or risks associated with the decision.

Deliverables

• A finalized ADR that documents the analysis and decision-making process.
• A clear proposed path forward for implementing the chosen solution to resolve the unimplemented state.

Benefits

By creating this ADR, we aim to:

• Provide a structured framework for addressing this limitation in flagd.
• Ensure the solution is well-documented and considers the needs of users and the maintainability of the system.
• Align development efforts with a clear, shared understanding of the architectural approach.

[aepfli]

relates also to #1797