Document design philosophies and reasonings for commonly challenged technical decisions

We frequently receive questions, issues, and pull requests that contradict already established decisions within the Prometheus team. When responding to them (or even to avoid some of them being filed in the first place), it would be great to have documented reasonings to link to. This would give both clarity and legitimacy to rejections.

We should document for each decision:

• Existing reasonings for it.
• Links to relevant discussions.
• Whether this decision is a permanent design decision or temporary due to lack of maintainability (like a moratorium on new SD mechanisms or not adding auth).
• Explanation of what the current consensus status is (formal vote vs. lazy consensus in team).
• Mechanisms of triggering an escalation / formal vote.

This has overlap with existing pages or ideas for pages:

• Existing FAQ page: this is similar to the FAQ page, but more about contentious issues and general design questions rather than regular usage questions.
• Planned non-goals documentation (https://github.com/prometheus/docs/issues/149): This could perhaps be part of the overall reasonings documentation.

To be determined:

• How should these overlapping areas be reconciled into a coherent whole?
• Should this documentation be centralized or should some specialized parts be kept distributed across repositories?
• How fine-granular should this documentation become? Probably not every minor decision should go in there that has been discussed one time somewhere on a GitHub issue. We should probably start with major points like overarching non-goals first and then see how it goes.

Start by reviewing the existing FAQ page and planned non-goals issue 149, then map where their scopes overlap. Resolve whether decision rationale should be centralized or distributed, how granular it should be, and how consensus and escalation are represented. Done means an agreed structure and documented reasoning for the initial major decisions.