Revise Keystone‑RS documentation layout and add missing sections

[gtema]

The project’s documentation needs a clear, layered structure so that the different audiences (operators, end‑users and developers) can find the information they need quickly.

Proposed sections

1. Administrative / Operations

   • Configuration guide – detailed steps for configuring the service (config file format, command‑line flags, environment variables, TLS/OPA setup, storage back‑ends, etc.).
   • Authentication & Authorization – how to bootstrap the admin user, token handling, policy integration, OPA policy‑file layout, and delegation model.

2. User (API) Guide

   • Overview of the public API versions (v3, v4) and supported endpoints.
   • Example request/response flows for the most‑used resources (projects, users, tokens, credentials, etc.).
   • Authentication flows (password, application‑credential, EC2, TOTP, WebAuthn, etc.) with example payloads.
   • Reference to the OpenAPI / Swagger specification.

3. Developer Guide

   • Architecture overview (domains, drivers, distributed storage, OPA integration).
   • How to extend the service (add a new backend driver, write a policy, contribute a new API module).
   • Testing strategy (unit tests, integration tests, raft profile, CI workflow).
   • Contribution checklist (coding style, license header, committed commit format, CI linting).

Additional notes

• Keep each top‑level heading as a separate markdown file under doc/ (e.g., admin.md, user.md, developer.md) and reference them from the main README.md.
• Add a Table of Contents at the top of the README that links to these sections.
• Mention the location of the generated OpenAPI spec (/doc/openapi.yaml) so users can explore the API with tools like Swagger UI.
• If any of the above content already exists elsewhere, add cross‑references instead of duplicating.

---